[PATCH] ne.c, 3c501.c, 3c503.c, 3c507.c: get rid of check_region()
Hi all,
check_region() patches attached. Next patchset will be ready in monday.
Best regards,
Andrey
--
diff -urN /mnt/disk/linux/drivers/net/3c501.c /linux/drivers/net/3c501.c
--- /mnt/disk/linux/drivers/net/3c501.c Tue Sep 12 23:47:56 2000
+++ /linux/drivers/net/3c501.c Thu Sep 28 20:48:23 2000
@@ -246,13 +246,8 @@
return -ENXIO;
for (i = 0; netcard_portlist[i]; i++)
- {
- int ioaddr = netcard_portlist[i];
- if (check_region(ioaddr, EL1_IO_EXTENT))
- continue;
- if (el1_probe1(dev, ioaddr) == 0)
+ if (el1_probe1(dev, netcard_portlist[i]) == 0)
return 0;
- }
return -ENODEV;
}
diff -urN /mnt/disk/linux/drivers/net/3c503.c /linux/drivers/net/3c503.c
--- /mnt/disk/linux/drivers/net/3c503.c Tue Sep 12 23:49:16 2000
+++ /linux/drivers/net/3c503.c Thu Sep 28 21:23:06 2000
@@ -154,14 +154,18 @@
int __init
el2_probe1(struct net_device *dev, int ioaddr)
{
-int i, iobase_reg, membase_reg, saved_406, wordlength;
+int i, iobase_reg, membase_reg, saved_406, wordlength, retval;
static unsigned version_printed = 0;
unsigned long vendor_id;
+if (!request_region(ioaddr, EL2_IO_EXTENT, "3c503"))
+ return -ENODEV;
+
/* Reset and/or avoid any lurking NE2000 */
if (inb(ioaddr + 0x408) == 0xff) {
mdelay(1);
- return -ENODEV;
+ retval = -ENODEV;
+ goto out;
}
/* We verify that it's a 3C503 board by checking the first three octets
@@ -171,7 +175,8 @@
/* ASIC location registers should be 0 or have only a single bit set. */
if ( (iobase_reg & (iobase_reg - 1))
|| (membase_reg & (membase_reg - 1))) {
- return -ENODEV;
+ retval = -ENODEV;
+ goto out;
}
saved_406 = inb_p(ioaddr + 0x406);
outb_p(ECNTRL_RESET|ECNTRL_THIN, ioaddr + 0x406); /* Reset it... */
@@ -183,7 +188,8 @@
if ((vendor_id != OLD_3COM_ID) && (vendor_id != NEW_3COM_ID)) {
/* Restore the register we frobbed. */
outb(saved_406, ioaddr + 0x406);
- return -ENODEV;
+ retval = -ENODEV;
+ goto out;
}
/* We should have a "dev" from Space.c or the static module table. */
@@ -191,8 +197,10 @@
printk("3c503.c: Passed a NULL device.\n");
dev = init_etherdev(0, 0);
- if (!dev)
- return -ENOMEM;
+ if (!dev) {
+ retval = -ENOMEM;
+ goto out;
+ }
}
if (ei_debug && version_printed++ == 0)
@@ -202,8 +210,9 @@
/* Allocate dev->priv and fill in 8390 specific dev fields. */
if (ethdev_init(dev)) {
printk ("3c503: unable to allocate memory for dev->priv.\n");
- return -ENOMEM;
- }
+ retval = -ENOMEM;
+ goto out;
+}
printk("%s: 3c503 at i/o base %#3x, node ", dev->name, ioaddr);
@@ -302,8 +311,6 @@
ei_status.block_input = &el2_block_input;
ei_status.block_output = &el2_block_output;
-request_region(ioaddr, EL2_IO_EXTENT, ei_status.name);
-
if (dev->irq == 2)
dev->irq = 9;
else if (dev->irq > 5 && dev->irq != 9) {
@@ -330,6 +337,9 @@
dev->name, ei_status.name, (wordlength+1)<<3);
}
return 0;
+out:
+release_region(ioaddr, EL2_IO_EXTENT);
+return retval;
}
static int
diff -urN /mnt/disk/linux/drivers/net/3c507.c /linux/drivers/net/3c507.c
--- /mnt/disk/linux/drivers/net/3c507.c Tue Sep 26 19:48:54 2000
+++ /linux/drivers/net/3c507.c Thu Sep 28 22:42:41 2000
@@ -317,13 +317,9 @@
else if (base_addr != 0)
return -ENXIO; /* Don't probe at all. */
- for (i = 0; netcard_portlist[i]; i++) {
- int ioaddr = netcard_portlist[i];
- if (check_region(ioaddr, EL16_IO_EXTENT))
- continue;
- if (el16_probe1(dev, ioaddr) == 0)
+ for (i = 0; netcard_portlist[i]; i++)
+ if (el16_probe1(dev, netcard_portlist[i]) == 0)
return 0;
- }
return -ENODEV;
}
@@ -331,7 +327,7 @@
static int __init el16_probe1(struct net_device *dev, int ioaddr)
{
static unsigned char init_ID_done = 0, version_printed = 0;
- int i, irq, irqval;
+ int i, irq, irqval, retval;
struct net_local *lp;
if (init_ID_done == 0) {
@@ -348,15 +344,21 @@
init_ID_done = 1;
}
- if (inb(ioaddr) == '*' && inb(ioaddr+1) == '3'
- && inb(ioaddr+2) == 'C' && inb(ioaddr+3) == 'O')
- ;
- else
+ if (!request_region(ioaddr, EL16_IO_EXTENT, "3c507"))
return -ENODEV;
+ if ((inb(ioaddr) != '*') || (inb(ioaddr + 1) != '3') ||
+ (inb(ioaddr + 2) != 'C') || (inb(ioaddr + 3) != 'O')) {
+ retval = -ENODEV;
+ goto out;
+ }
+
/* Allocate a new 'dev' if needed. */
Re: i815e related
On Fri, 29 Sep 2000, Art Boulatov wrote: > Alan Cox wrote: > > > > Is AD1881A (AC'97 audio) codec supported? > > > > Sort of - it mostly works nowdays but mic recording is unsupported still. > > Its solid in 2.2.18pre so should be solid in 2.4.0test9 > > Ok, thanks, > > One more thing I'm concerned about (which is not really kernel related), > does the sound processing with AC'97 interface have any impact on > overall > system perfomance in comparison to PCI cards sound processing? I can't say specifically for the i815, but the presence or lack of AC97 support shouldn't affect performance.. The i815 audio is low-cost, simple audio solution. If you want something fully featured, you'll want a PCI card. But that is a choice based on features, not performance.. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Buffers, Blocks and Lockups
HI I borrowed the block_write code from fs/block_dev.c. When I am doing a write the task locks up in schedual() - wait_on_buffer(). This means that the buffer is locked, and stays locked. The funny thing is when I do a 'dd if=/dev/zero of=/dev/igf0 bs=1024 count=16' the driver works and write zeros. But when I open the device in a different program, it locks up. The first block is written the it hangs. I have put printk() of the buffer flags and both (dd and my program)look the same. I am writting to a flash device that does not produce interrupts. I am waiting for sourceforge to give me a project so I can post the source. but fs/block_dev.c block_write() is the same code, almost Shaun Savage - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Russell King forks ARM Linux.u
Ralf Baechle wrote: > > On Wed, Sep 27, 2000 at 02:48:47PM -0700, H. Peter Anvin wrote: > > > The only thing I'm not sure is that I believe the SPARC people uses > > ttyS* for Zilog 8530-based serial ports. I don't know if we want to > > define this as NS8250-family serial ports in light of that; I more > > tended to think of it as the "default" serial port for the > > architecture. > > > > It's mostly up to the SPARC people, I guess... > > Anything else would mean the user of the serial port has to know about > the machines exact configuration on boxes like MIPS which can be tricky > in case of some machines and configurations. > That's more a matter of what ports are available, etc, etc. You really need to handle that properly anyway. -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] Please read the FAQ at http://www.tux.org/lkml/
Re: Removing boot text
On Thu, 28 Sep 2000, Richard B. Johnson wrote: > On Thu, 28 Sep 2000, Paul Powell wrote: > > > We are using Linux as a bootable CD for system > > configuration. We would like to keep all the > > information displayed at bootup hidden. The main > > reason for this is because our users see words such as > > "error" and "failed" and it bothers them (though there > > is nothing wrong). > > > > Anyone know how other than changing the kernel code? > > > > Thanks > > > > The stuff that is written in the kernel by printk() can be configured > to go to an RS-232C port. This has to be compiled into the kernel. > You use append="console=ttyS0,BAUDRATE" in LILO configuration. This > keeps it off the screen. > > The stuff written by init, can be eliminated by changing the link > of /dev/console to point to /dev/null instead of /dev/tty0. There is a dummy console also, might be in drivers/video because it is associated with fbdev. That sounds like the best solution.. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[BUG-FIX] Alpha needs some defines
Hi Linus,
This part was missing from the leases & directory notification
patch that was applied to 2.4.0-test9pre5. Please apply.
Cheers,
Stephen
--
Stephen Rothwell, Open Source Researcher, Linuxcare, Inc.
+61-2-62628990 tel, +61-2-62628991 fax
[EMAIL PROTECTED], http://www.linuxcare.com/
Linuxcare. Support for the revolution.
diff -ruN 2.4.0-test9pre7/include/asm-alpha/fcntl.h
2.4.0-test9pre7-UFL/include/asm-alpha/fcntl.h
--- 2.4.0-test9pre7/include/asm-alpha/fcntl.h Thu Aug 24 17:52:14 2000
+++ 2.4.0-test9pre7-UFL/include/asm-alpha/fcntl.h Wed Sep 27 02:30:11 2000
@@ -48,6 +48,9 @@
#define F_EXLCK16 /* or 3 */
#define F_SHLCK32 /* or 4 */
+/* for leases */
+#define F_INPROGRESS 64
+
/* operations for bsd flock(), also used by the kernel implementation */
#define LOCK_SH1 /* shared lock */
#define LOCK_EX2 /* exclusive lock */
@@ -55,6 +58,10 @@
blocking */
#define LOCK_UN8 /* remove lock */
+#define LOCK_MAND 32 /* This is a mandatory flock */
+#define LOCK_READ 64 /* ... Which allows concurrent read operations */
+#define LOCK_WRITE 128 /* ... Which allows concurrent write operations */
+
struct flock {
short l_type;
short l_whence;
@@ -66,5 +73,7 @@
#ifdef __KERNEL__
#define flock64flock
#endif
+
+#define F_LINUX_SPECIFIC_BASE 1024
#endif
diff -ruN 2.4.0-test9pre7/include/asm-alpha/resource.h
2.4.0-test9pre7-UFL/include/asm-alpha/resource.h
--- 2.4.0-test9pre7/include/asm-alpha/resource.hFri Feb 18 04:35:07 2000
+++ 2.4.0-test9pre7-UFL/include/asm-alpha/resource.hWed Sep 27 02:33:04 2000
@@ -15,8 +15,9 @@
#define RLIMIT_AS 7 /* address space limit(?) */
#define RLIMIT_NPROC 8 /* max number of processes */
#define RLIMIT_MEMLOCK 9 /* max locked-in-memory address space */
+#define RLIMIT_LOCKS 10 /* maximum file locks held */
-#define RLIM_NLIMITS 10
+#define RLIM_NLIMITS 11
/*
* SuS says limits have to be unsigned. Fine, it's unsigned, but
@@ -39,6 +40,7 @@
{LONG_MAX, LONG_MAX}, /* RLIMIT_AS */ \
{LONG_MAX, LONG_MAX}, /* RLIMIT_NPROC */ \
{LONG_MAX, LONG_MAX}, /* RLIMIT_MEMLOCK */\
+{LONG_MAX, LONG_MAX}, /* RLIMIT_LOCKS */ \
}
#endif /* __KERNEL__ */
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
RE: Linux kernel modules development in C++
> -Original Message- > From: Horst von Brand [mailto:[EMAIL PROTECTED]] > Sent: Thursday, September 28, 2000 1:45 PM [snip] > When Linux started, there was _no_ decent freeware C++ > compiler around. IMO, it was worse even than that. C++ itself hadn't stablized as a language to the point where it would have been wise to use on a kernel at that time. The language only really stablized in '99, I think. It's too soon to tell whether it would be usable for kernel development, although various projects that have tried to use it in an OO way have floundered for one reason or another. BTW, C++ isn't really a pure OO language, it is a language that has facilities that support a wide range of programming paradigms. One of the things that makes it hard to use effectively is taking that into account when using its various facilities. Marty - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: hdb errors with 2.2.16
"Alexander Valys" <[EMAIL PROTECTED]> said: > I haven't done either. I have booted linux in the following manner (no OS > is installed at this point). > 1. Turn on Computer > 2. Put CD in while RAM is counting > 3. view slackware boot prompt > 4. press enter > 5. watch kernel messages scroll by. > 6. format disks > 7. -- errors -- > Any other ideas? The disk is less than a year old. Broken disk, overclocked CPU, overheated CPU, bad RAM, bad controller, bad IDE cable, cable not seated right, cable is too near a source of electrical interference, cable too long, ... I've seen cases where you needed to cold reboot the machine after partitioning (dumb BIOS?). In any case, without further details about the errors, anything we could tell you is just (wild) guesses. -- Horst von Brand [EMAIL PROTECTED] Casilla 9G, Vin~a del Mar, Chile +56 32 672616 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.2.18pre11
On Thu, Sep 28, 2000 at 09:23:42PM -0400, Horst von Brand wrote: >Alan Cox <[EMAIL PROTECTED]> said: >> > - Only 64 of 96 mbytes ram was found > >> BIOS issue > >Yes, but here 2.4.0test do find all 128Mb. Really dunno if latest 2.2.18pre >get it right, should check some day... Hi, As far as I know, and Alan can correct me if I'm wrong, 2.2.x doesn't support e820h bios call, only the e801h call. The problem is that a lot of these newer bioses dropped the e801h from the bios, and only have 88h and e820h. As a result, 2.2.x will report 64Mb, since the only call that works is 88h. 2.4.0test on the other hand supports e820h, which is why 2.4.0test gets the memory size correct. -Harold -- "Life sucks, deal with it!" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Interrupt/Sleep deadlock
You could use a semaphore for this. Initialize it to 0, then call down() from the ioctl, and up() from the interrupt handler. If the up() happens before the down(), the down() won't go to sleep. Nigel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
How to access IO memory space when Linux-2.2.14 running?
Hi all,
I am programming a device driver on PLX9060 chipset, and want to config DMA
controller by IO memory,
but I find that can't access them in regular way,below are my codes.
>cat /proc/pci
Bus 0, device 16, function 0:
Bridge: PLX Unknown device (rev 3).
Vendor id=10b5. Device id=9060.
Medium devsel. Fast back-to-back capable. IRQ 12. Master Capable.
Latency=64. Min Gnt=8.Max Lat=8.
Non-prefetchable 32 bit memory at 0xe710 [0xe710].
I/O at 0xe400 [0xe401].
Non-prefetchable 32 bit memory at 0xe700 [0xe700].
I want to access the virtual address of 0xe700 by ioremap()
struct dev {
u32 mem;
u32 io;
u32 space0;
...
};
mem = 0xe710;
io = 0xe400;
space0 = 0xe700;
ulong * remap = (ulong *)ioremap_nocache(space0, 0x200);
remap =remap + (0x100>>2);
/* check the return value of ioremap by printk()
* remap = 0xc2059100;
*/
/*
* Now test to see if I can access the DMA registers
* If I write -1 and get back 1FFF, then we accessed the
* DMA register, isn't it?
* there are two methods: remap[0x00] =x, writel(x, remap + 0x00), but I don't know
their difference.
*/
remap[0x00] = 0x;
/* check the return value of remap by printk()
* remap[0x00] = 0x;
* remap[0x01] = 0x;
* remap[0x02] = 0x;
* remap[0x03] = 0x;
* remap[0x04] = 0x;
* remap[0x05] = 0x;
*/
then rerun the module
writel(0x03, remap + 0x00);
/* check the return value of remap by readl()
* remap + 0x00 = 0x0003;
* remap + 0x01 = 0x0003;
* remap + 0x02 = 0x0003;
* remap + 0x03 = 0x0003;
* remap + 0x04 = 0x0003;
* remap + 0x05 = 0x0003;
* remap + 0x06 = 0x0003;
*/
so, I think probably access error,
I don't know how to update my code to access DMA registers.
any helps are appreciated.
thanks in advance.
-Jim
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Posting to this list without 500 bounces?
On Thu, Sep 28, 2000 at 08:25:09PM +, Miquel van Smoorenburg wrote: > In article <3776575819.970144217@[10.10.1.2]>, > And unreliable ISP SMTP servers? Hard to imagine, as 99.5% of the > userbase undoubtedly uses that SMTP server and I can't believe > that a reasonable ISP randomly drops email messages. Here in Spain a good number of ISPs are extremely reliable. They must be, since they have the habit of upgrading or going through "scheduled" maintenance. ;) And you don't even want to hear about usenet, radius, disconnections, or cable/adsl deployment. Once T, _the_ phone co lost connectivity to the rest of the world, and they said a excavator had cut the fiber. I emailed their backbone provider and found out that T decieded not to keep the contract, so their provider cut them off. (Eventually newspapers called it the "ghost excavator":) Umm... back to on-topicness :) -- /| Ragnar Højland Freedom - Linux - OpenGL Fingerprint 94C4B \ o.O| 2F0D27DE025BE2302C =(_)= "Thou shalt not follow the NULL pointer for 104B78C56 B72F0822 U chaos and madness await thee at its end." hkp://keys.pgp.com Handle via comment channels only. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux kernel modules development in C++
On Thu, Sep 28, 2000 at 04:44:55PM -0400, Horst von Brand wrote: > Ragnar Hojland Espinosa <[EMAIL PROTECTED]> said: > > On Thu, Sep 28, 2000 at 01:45:40AM +0200, Igmar Palsenberg wrote: > > Let's put it the other way... there aren't many people who know C++ > > around. Well, there are less people who understand the kernel. Then, > > maybe, to make it more accessible, we should dumb it down. > > It is not necessarily a good thing that everybody and her grandmother think > they can hack on Linux... exhibit A for the defense: Look at the average > skill level of your run-of-the-mill $GUI_WORDPROCESSOR user: Sure, they are Yes, yes.. I should had added some ;) smiley there; I was trying to point out that the fact that not all mainstream kernel hackers know (or like;) C++ shouldn't be IMO a reason to put it aside. [ Disclaimer: Please note I'm not advocating for C++ifying the kernel; we all know it wouldn't be a good idea as it is. ] -- /| Ragnar Højland Freedom - Linux - OpenGL Fingerprint 94C4B \ o.O| 2F0D27DE025BE2302C =(_)= "Thou shalt not follow the NULL pointer for 104B78C56 B72F0822 U chaos and madness await thee at its end." hkp://keys.pgp.com Handle via comment channels only. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4-test9 kernel header flaw
On Fri, Sep 29, 2000 at 01:41:09AM +0200, Andries Brouwer wrote: > On Thu, Sep 28, 2000 at 03:41:41PM -0700, Jack Howarth wrote: > > > I find that the compile of gnome-utils fails as follows... > > > > In file included from /usr/include/linux/string.h:21, > > from /usr/include/linux/fs.h:23, > > from badblocks.c:43: > > Yes, a well-known phenomenon. > Kernel headers are to compile the kernel. > They are not for inclusion in user programs. Yes. I think what Jack was saying is it doesn't seem anyways like the kernel needs to include linux/string.h in fs.h. If it does need linux/string.h either a) The #include should be in #ifdef __KERNEL__/#endif or the contents of linux/string.h should be in #ifdef __KERNEL__/#endif. -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Interrupt/Sleep deadlock
Heh.. I needed to figure this out about 6 months ago. Here's the "right answer" Before sending the command to the board, call set_current_state(TASK_UNINTERRUPTIBLE). This will prevent the scheduler from interrupting your task, but more importantly it will prevent your task from being re-scheduled (once you give up control) until the task is woken up (which sets the state to TASK_RUNNING). Then, send the command to the board. Then call schedule() or schedule_timeout() -- that won't return until your task is at TASK_RUNNING. Now, if the interrupt fires before you call schedule, then schedule will simply reschedule. But, the wakeup re-set the state to TASK_RUNNING for you, so your task _will_ get rescheduled (avoiding the deadlock). See linux/drivers/usb/storage/transport.c usb_stor_bulk_msg() for the code I wrote that uses this. The key is in setting TASK_UNINTERRUPTABLE _before_ you send the command, so that it doesn't race with the interrupt. Matt On Thu, Sep 28, 2000 at 06:26:17PM -0700, Ivan Passos wrote: > > Hello, > > In order to get the configuration of a board, I have to send, from > userspace, an ioctl to the driver and wait for the board to complete its > action. The way this is implemented is as follows: > - In the ioctl, the driver sends a command to the board and then goes to > sleep (interruptible_sleep_on(&info->config_wait)); > - The board receives the command, handles it and answers back with an > interrupt; > - The driver's interrupt handler schedules a bottom-half action. > - The bottom-half calls wake_up_interuptible(&info->config_wait). > - The ioctl returns and the userspace application has the board > configuration. > > Now, the problem: the board is so fast that it interrupts back _before_ > the driver goes to sleep, i.e.: > - Driver sends command to board; > - Driver goes to sl... interrupt back from board!! > - Interrupt handler schedules bottom-half. > - Bottom-half calls wake_up. > - Ioctl continues, and _then_ goes to sleep. System locked. > > I can't disable interrupts before going to sleep, because the event that > wakes me up is an interrupt. However, if I don't protect it from the > interrupts, the system locks ... > > Is there any other way in Linux to implement this?!?!?! > > Thanks in advance for any help. > > Later, > Ivan > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver C: They kicked your ass, didn't they? S: They were cheating! -- The Chief and Stef User Friendly, 11/19/1997 PGP signature
Interrupt/Sleep deadlock
Hello, In order to get the configuration of a board, I have to send, from userspace, an ioctl to the driver and wait for the board to complete its action. The way this is implemented is as follows: - In the ioctl, the driver sends a command to the board and then goes to sleep (interruptible_sleep_on(&info->config_wait)); - The board receives the command, handles it and answers back with an interrupt; - The driver's interrupt handler schedules a bottom-half action. - The bottom-half calls wake_up_interuptible(&info->config_wait). - The ioctl returns and the userspace application has the board configuration. Now, the problem: the board is so fast that it interrupts back _before_ the driver goes to sleep, i.e.: - Driver sends command to board; - Driver goes to sl... interrupt back from board!! - Interrupt handler schedules bottom-half. - Bottom-half calls wake_up. - Ioctl continues, and _then_ goes to sleep. System locked. I can't disable interrupts before going to sleep, because the event that wakes me up is an interrupt. However, if I don't protect it from the interrupts, the system locks ... Is there any other way in Linux to implement this?!?!?! Thanks in advance for any help. Later, Ivan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.2.18pre11
Alan Cox <[EMAIL PROTECTED]> said: > > - Only 64 of 96 mbytes ram was found > BIOS issue Yes, but here 2.4.0test do find all 128Mb. Really dunno if latest 2.2.18pre get it right, should check some day... -- Horst von Brand [EMAIL PROTECTED] Casilla 9G, Vin~a del Mar, Chile +56 32 672616 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: reading 1 hardsector size, not one block size
At 00:40 29/09/2000, [EMAIL PROTECTED] wrote: >I'm writing some code to grok the Intel EFI GUID Partition Table structures. >To to so, my partition reading code (in fs/partitions) needs to be able to >read one physical sector at a time, particularly the first and last sectors >on the disk. The bread() function ultimately calls ll_rw_block(), which >checks that my read size is the same as the block size, which is 1024 for a >SCSI disk, while the physical sector size is 512 bytes. The EFI Spec calls >for reading/writing on the physical block size. > >In the case of reading the first sector, I could read 2 sectors and throw >away the bottom half. >In the case of reading the last sector, I have to read the last 2 sectors >and throw away the top half (assuming the disk has an even number of >512-byte sectors). And if it has an odd number then you can't read the last sector at all! - That's what prevents linear raid and proper NTFS support from working on "odd sized" partitions... I don't see any Clean Way(TM) to fix this, as well as your "EFI Spec calling for physical block size" problem, apart from changing the kernel BLOCK_SIZE to 512 (from the current 1024) and picking up the pieces afterwards... - I would be very happy if someone tells me I am wrong! (-; Note that I don't think adding any form of hacks into partition table / file system code to allow low-level access to the underlying device can be considered a Clean Way(TM) since such code has no business dealing with what device it is on. The only thing that such code has business dealing with is logical access to the particular partition in question. This is all IMHO... I doubt that such a change would be accepted for 2.4 at such a late stage considering making the change breaks just about every block device driver and at least the ext2 file system (read: kernel doesn't boot if the change is done!). - Having said that, my development PC actually is running a kernel with BLOCK_SIZE = 512 but I had to do a few modifications to get it to work. (-: It became apparent that despite that the code in many source files in the kernel uses BLOCK_SIZE macro it at the same time assumes that it equals 1024, which is, IMHO, a strange thing to assume to say the least, but anyway, all those places have to be fixed first. - Ext2 is pretty much ok except for the fact that you need to start using the (already existing) MIN_EXT2_BLOCKSIZE macro in fs/ext2/super.c and you have to change the super_block location calculation in the same place. - My current tree (based on 2.4.0-test8+various patches) has fixed drivers/ide/hd.c, drivers/scsi/sd.c, drivers/scsi/scsicam.c(?), fs/ext2/super.c and fs/partitions/check.c so that the code works for any definition of BLOCK_SIZE (well, at least for any sane definition...) and this makes it work both with my IDE and SCSI hard disks and ext2 partitions as well as with my current devel tree version of NTFS, now being able to read the last sector on odd sized partitions. - Also reads (open(2)/read(2) on /dev/[hs]daX, for various X tested) now allow me to see all sectors. - The kernel also "feels" faster but that might be just wishful thinking/timing coincidence... no benchmarks available... What I am fairly certain is now broken due to changing BLOCK_SIZE to 512: ramdisk+initrd, floppy disk(?) and raid. I have started working on the latter but I haven't gotten it to work yet. )-: Note that all my above changes don't break anything if BLOCK_SIZE is left at 1024. I am planning on updating my patches when 2.5 comes out and start submitting them slowly to the various maintainers so that it should eventually be just possible to just change BLOCK_SIZE to 512 and recompile and it then all automagically works but that might be some time away... Regards, Anton >In the case of reading exactly one sector from the middle of the disk, it's >similar to either the first or second case. >To read say 32 sectors anywhere on the disk, I have to do 1024-byte aligned >bread()s, possibly doing an unaligned first block, aligned middle, and >unaligned last block. > >Is there an easier method? > >Thanks, >Matt > > > > >- >To unsubscribe from this list: send the line "unsubscribe linux-kernel" in >the body of a message to [EMAIL PROTECTED] >Please read the FAQ at http://www.tux.org/lkml/ -- "Education is what remains after one has forgotten everything he learned in school." - Albert Einstein -- Anton Altaparmakov Voice: 01223-333541(lab) / 07712-632205(mobile) Christ's CollegeeMail: [EMAIL PROTECTED] Cambridge CB2 3BUICQ: 8561279 United Kingdom WWW: http://www-stu.christs.cam.ac.uk/~aia21/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: hdb errors with 2.2.16
I haven't done either. I have booted linux in the following manner (no OS is installed at this point). 1. Turn on Computer 2. Put CD in while RAM is counting 3. view slackware boot prompt 4. press enter 5. watch kernel messages scroll by. 6. format disks 7. -- errors -- Any other ideas? The disk is less than a year old. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Andre Hedrick Sent: Wednesday, September 27, 2000 22:05 To: Alexander Valys Cc: [EMAIL PROTECTED] Subject: Re: hdb errors with 2.2.16 If you launched out of Windows to install Linux, DON'T do that. If you have booted into Linux from Windows, DON'T do that. I can fix a lot of things that MS does to the ATA-Bridge/Chipset but I do not like to go dorking int the PCI/ISA bridges to fix up issues. Cheers, Andre Hedrick The Linux ATA/IDE guy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: i815e related
Alan Cox wrote: > > Is AD1881A (AC'97 audio) codec supported? > > Sort of - it mostly works nowdays but mic recording is unsupported still. > Its solid in 2.2.18pre so should be solid in 2.4.0test9 Ok, thanks, One more thing I'm concerned about (which is not really kernel related), does the sound processing with AC'97 interface have any impact on overall system perfomance in comparison to PCI cards sound processing? Art. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] enabling APIC and NMI watchdog on UP systems
On Fri, 29 Sep 2000 03:03:30 +0200 (CEST), Ingo Molnar <[EMAIL PROTECTED]> wrote: > >On Fri, 29 Sep 2000, Keith Owens wrote: > >> [...] You prefer to make NMI for UP mandatory, change the existing >> behaviour and force people who use performance counters to turn off >> EVNTSEL1 themselves. [...] > >no, AFAIK there is no performance counter support in the vanilla kernel, >but there is an NMI oopser. arch/i386/kernel/msr.c has been there since at least 2.4.0-test1. A web search reveals a lot of other patches for performance counter libraries on Linux. http://www.scl.ameslab.gov/Projects/Rabbit/ is a good start, it indicates that people are already using the counters. >And even if there was performance counter >support, having a default NMI oopser on UP *is* a much higher priority. Agreed, having the support is a high priority. Changing the default behaviour of the performance counters is where we differ. >and there is no forcing here. nmi_watchdog=0 on bootup and the NMI >watchdog is disabled. (right now this is not enforced for the APIC-NMI, >but thats a detail.) I originally did that but it users have to tweak their boot files whenever they install a new kernel. Making it a config option propagates the user's requirements from one kernel build to another. Let's just agree to disagree and put your patch in the mainline kernel. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: APM Problems
There is no APM support in the BIOS on the Dell Inspiron 5000e - it's ACPI only. Thanks, Matt > > -Original Message- > From: Tom Sightler [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, September 27, 2000 3:59 PM > To: Linux-Kernel > Subject: APM Problems > > Hi All, > > I'm having a problem related to APM on my Dell Inspiron 5000e (just > arrived a few > days ago). I installed Redhat 7.0 and upon reboot was immediately > greeted by > scrolling oops screens. The system did boot on up and upon further > examintation > I found the errors were caused by the attempt to start apmd. Acutally, > any > access to /proc/apm would generate a non-fatal oops > (general protection > fault). > > I compiled a standard 2.2.17 and 2.4.0-test9-pre7 but both experience > exactly the > same symptom, any access to /proc/apm and you get an oops. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] enabling APIC and NMI watchdog on UP systems
On Fri, 29 Sep 2000, Keith Owens wrote: > [...] You prefer to make NMI for UP mandatory, change the existing > behaviour and force people who use performance counters to turn off > EVNTSEL1 themselves. [...] no, AFAIK there is no performance counter support in the vanilla kernel, but there is an NMI oopser. And even if there was performance counter support, having a default NMI oopser on UP *is* a much higher priority. and there is no forcing here. nmi_watchdog=0 on bootup and the NMI watchdog is disabled. (right now this is not enforced for the APIC-NMI, but thats a detail.) Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] enabling APIC and NMI watchdog on UP systems
On Fri, 29 Sep 2000 01:13:06 +0200 (CEST), Ingo Molnar <[EMAIL PROTECTED]> wrote: >On Fri, 29 Sep 2000, Keith Owens wrote: >> Using performance counter 1 for NMI conflicts with using the >> performance counters for tuning. IMHO it is better to default to NMI >> off for UP so we do not disturb people who are doing performance >> monitoring. [...] > >the number of people experiencing hard lockups, and the importance of >debugging these (annoying) lockups IMO far outweighs the potential >inconvenience caused by having to disable the NMI oopser for performance >tuning. I did not want to disturb anybody who was already using the performance counters for tuning so I made NMI for UP optional. You prefer to make NMI for UP mandatory, change the existing behaviour and force people who use performance counters to turn off EVNTSEL1 themselves. And they must remember to reprogram EVNTSEL1 to reactivate NMI after they have finished tuning. This is a philosophical difference, not a technical one, we will just have to agree to disagree. Either way it will be nice to get NMI for UP into the standard kernel. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: i815e related
On Fri, 29 Sep 2000, Alan Cox wrote: > > Is the 82801BA Contoller Hub (ICH2) supported (would I get ATA-100 > > working)? > > It will work. I dont know if you'll get ATA100 with 2.4test. You wont with > 2.2 Yes ICH2 is native. Andre Hedrick The Linux ATA/IDE guy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
reading 1 hardsector size, not one block size
I'm writing some code to grok the Intel EFI GUID Partition Table structures. To to so, my partition reading code (in fs/partitions) needs to be able to read one physical sector at a time, particularly the first and last sectors on the disk. The bread() function ultimately calls ll_rw_block(), which checks that my read size is the same as the block size, which is 1024 for a SCSI disk, while the physical sector size is 512 bytes. The EFI Spec calls for reading/writing on the physical block size. In the case of reading the first sector, I could read 2 sectors and throw away the bottom half. In the case of reading the last sector, I have to read the last 2 sectors and throw away the top half (assuming the disk has an even number of 512-byte sectors). In the case of reading exactly one sector from the middle of the disk, it's similar to either the first or second case. To read say 32 sectors anywhere on the disk, I have to do 1024-byte aligned bread()s, possibly doing an unaligned first block, aligned middle, and unaligned last block. Is there an easier method? Thanks, Matt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: i815e related
> Is the 82801BA Contoller Hub (ICH2) supported (would I get ATA-100 > working)? It will work. I dont know if you'll get ATA100 with 2.4test. You wont with 2.2 > Is AD1881A (AC'97 audio) codec supported? Sort of - it mostly works nowdays but mic recording is unsupported still. Its solid in 2.2.18pre so should be solid in 2.4.0test9 > > There's also onboard 3C905C NIC ASIC, > would that work with 3C905 driver? Probably - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux kernel modules development in C++
On Fri, 29 Sep 2000, Daniel Phillips wrote: > Horst von Brand wrote: > > This is exactly what Linus meant when he said he doesn't want an in-kernel > > debugger: Dumb it down, and you select dumber hackers, and the result is a mess. > > So you must be in favor of removing all > comments from the kernel source, in order to select even less dumb > hackers? What makes you think that lack of comments would stop the dumb ones? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
PATCH: Fix to slab.c for SMP (test9-pre7) (v2)
Hi
After some rethought over the patch (and feedback from Linus)
I have made another version that should work also on SMP
Sparc.
As always, any comment/feedback/Bug reports/... are welcome.
Later, Juan.
ChangeLog:
v2.0:
- shrink_[id]_caches don't return the number of freed pages, and then
I change the code to reflect that. Just now with per-CPU caches, it
is difficult to make the bookkeeping, with NUMA, things will get only
worse.
- Now, we call smp_call_function with single functions (i.e. don't use
spinlocks). That last point was the problem with Sparcs.
- slab_cache_all_sync changes name to smp_call_function_all_cpus (it
could be a good idea to make that function in a library).
- For freeing the slabs, we now use the same _trick_ that
kmem_tune_cpucache(). The only difference is that, as we are low on
memory, we can't allocate a new cpucache_t*new[] to do the swap. To
resolve that, we change the previous one for NULLs (with an
smp_call_function), we free the slabs (now we are in normal kernel
space, spinlocks/waits/... are safe). And once finished, we assign:
->avail = 0 and set that arrays again with smp_call_function.
Notice that we are serialising that operations with cache_chain_sem,
that means that we can't never mesh the state.
- This last change allowed us to share (indeed) more code with the
case of create the cache.
v1.0:
- shrink_[id]_caches return the count of the freed pages (from ingo
and marelo patch)
- removes the ret variable in smp_call_function (it was unused)
- removes the slab_cache_drain_mask/slab_drain_local_cache and its
references for the timer interrupt code. That calls are now done
with smp_call_function, that lets us to simplify a lot the code (we
don't need the cache_drain_wait queue anymore.
- Change the cache_drain_sem semaphore to cache_all_lock spinlock, as
now we never sleep/schedule while holding it. The name is changed
because it is not only used by the drain rutines it is also used by
the update ones.
- slab_drain_local_cache is divided in the functions:
slab_drain_local_cache
do_ccupdate_local
as we known a compile time _which_ part of the function we want to
call.
- pass the spinlock calls inside slab_cache_all_sync, as they are
needed only when calling that function. The wait queue is not
needed anymore. This function used global variables to pass
arguments to slab_drain_local_cache, that has been changed to use
global arguments.
- do_ccupdate & drain_cpu_caches code has been refunded inside
slab_cache_all_sync, as the same code except for one line.
- In the proccess, the net result are ~40 less lines of code
Thanks to Phillip Rumpf, Stephen Tweedie, Alan Cox, Ingo & the rest of the
people that explained me the SMP/cross CPU mysteries.
diff -urN --exclude-from=/home/lfcia/quintela/work/kernel/exclude
base/arch/i386/kernel/smp.c working/arch/i386/kernel/smp.c
--- base/arch/i386/kernel/smp.c Tue Sep 26 03:46:03 2000
+++ working/arch/i386/kernel/smp.c Wed Sep 27 23:45:30 2000
@@ -464,7 +464,7 @@
*/
{
struct call_data_struct data;
- int ret, cpus = smp_num_cpus-1;
+ int cpus = smp_num_cpus-1;
if (!cpus)
return 0;
@@ -485,7 +485,6 @@
while (atomic_read(&data.started) != cpus)
barrier();
- ret = 0;
if (wait)
while (atomic_read(&data.finished) != cpus)
barrier();
diff -urN --exclude-from=/home/lfcia/quintela/work/kernel/exclude base/fs/dcache.c
working/fs/dcache.c
--- base/fs/dcache.cTue Sep 26 03:34:00 2000
+++ working/fs/dcache.c Thu Sep 28 17:15:28 2000
@@ -551,7 +551,7 @@
* ...
* 6 - base-level: try to shrink a bit.
*/
-int shrink_dcache_memory(int priority, unsigned int gfp_mask)
+void shrink_dcache_memory(int priority, unsigned int gfp_mask)
{
int count = 0;
@@ -567,19 +567,13 @@
* block allocations, but for now:
*/
if (!(gfp_mask & __GFP_IO))
- return 0;
+ return;
if (priority)
count = dentry_stat.nr_unused / priority;
+
prune_dcache(count);
- /* FIXME: kmem_cache_shrink here should tell us
- the number of pages freed, and it should
- work in a __GFP_DMA/__GFP_HIGHMEM behaviour
- to free only the interesting pages in
- function of the needs of the current allocation. */
kmem_cache_shrink(dentry_cache);
-
- return 0;
}
#define NAME_ALLOC_LEN(len)((len+16) & ~15)
diff -urN --exclude-from=/home/lfcia/quintela/work/kernel/exclude base/fs/inode.c
working/fs/inode.c
--- base/fs/inode.c Tue Sep 26 03:34:00 2000
+++ working/fs/inode.c Thu Sep 28 17:15:40 2000
@@ -454,7 +454,7 @@
dispose_list(freeable);
}
-int shrink_icache_memory(int priority, int gfp_mask)
+void shrink_icache_memory(int priority, int gfp_mask)
{
int count = 0;
Re: Linux 2.4-test9 kernel header flaw
On Thu, Sep 28, 2000 at 03:41:41PM -0700, Jack Howarth wrote: > I find that the compile of gnome-utils fails as follows... > > In file included from /usr/include/linux/string.h:21, > from /usr/include/linux/fs.h:23, > from badblocks.c:43: Yes, a well-known phenomenon. Kernel headers are to compile the kernel. They are not for inclusion in user programs. (This fact of life means that one has to use a private copy. That is good, keeps the source stable, also when the kernel changes. But it is also bad - such information as structure definitions and manifest constants ought to be in a single place, used by libc and kernel. I get the impression that Linus will accept a nice rewrite of all includes. Remains the question what wishes Ulrich has on a revised setup. So far Ulrich has not answered - let me cc him and see whether he has an opinion now.) Andries - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Removing boot text
On Thu, Sep 28, 2000 at 11:06:47PM +0100, Alan Cox wrote: > > is nothing wrong). > > > > Anyone know how other than changing the kernel code? > > You need to change the initial kernel message logging level to be higher > yes lower, actually. putting "quiet" in the command line should work for everything but ill-behaved drivers (which should be fixed anyway). - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
i815e related
Hi, Our company is going to purchase some hardware to run Linux workstations. We're looking forward into getting i815e based ASUS motherboards, and I will be really glad if you could help me figure out the following hardware support questions I couldn't figure myself. I've searched the LKML archive and Intel and few other sites, but didn't find enough straightforward answers concerning the more/less complete Linux support of ASUS CUSL2-M (i815e) motherboard, (http://www.asus.com.tw/products/motherboard/pentiumpro/cusl2-m/spec.html) Here are the things: Is the 82801BA Contoller Hub (ICH2) supported (would I get ATA-100 working)? Searching through drivers/pci/pci.ids (test9-pre7), I found 82801AB (ICH0?) only. Is AD1881A (AC'97 audio) codec supported? There's also onboard 3C905C NIC ASIC, would that work with 3C905 driver? Thanks a lot, Art. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux kernel modules development in C++
Horst von Brand wrote: > This is exactly what Linus meant when he said he doesn't want an in-kernel > debugger: Dumb it down, and you select dumber hackers, and the result is a mess. So you must be in favor of removing all comments from the kernel source, in order to select even less dumb hackers? -- Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.2.18pre11
On Fri, 29 Sep 2000, Eyal Lebedinsky wrote: > Alan Cox wrote: > > > > 2.2.18pre11 > > I should mention that using an almost-all-modularised config I get this > for the last few pachlevels: > > depmod: *** Unresolved symbols in /lib/modules/2.2.18pre11/misc/rio.o This patch fixes this: --- linux.orig/drivers/char/MakefileWed Sep 20 18:20:16 2000 +++ linux/drivers/char/Makefile Wed Sep 20 18:22:53 2000 @@ -201,13 +201,14 @@ endif obj-$(CONFIG_SX) += sx.o generic_serial.o -obj-$(CONFIG_RIO) += rio/rio.o generic_serial.o ifeq ($(CONFIG_RIO),y) +L_OBJS += rio/rio.o generic_serial.o SUB_DIRS += rio MOD_SUB_DIRS += rio else ifeq ($(CONFIG_RIO),m) + M_OBJS += generic_serial.o MOD_SUB_DIRS += rio endif endif - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Russell King forks ARM Linux.u
On Wed, Sep 27, 2000 at 02:48:47PM -0700, H. Peter Anvin wrote: > The only thing I'm not sure is that I believe the SPARC people uses > ttyS* for Zilog 8530-based serial ports. I don't know if we want to > define this as NS8250-family serial ports in light of that; I more > tended to think of it as the "default" serial port for the > architecture. > > It's mostly up to the SPARC people, I guess... Anything else would mean the user of the serial port has to know about the machines exact configuration on boxes like MIPS which can be tricky in case of some machines and configurations. Ralf - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Linux 2.4-test9 kernel header flaw
Hello, In building the RedHat 7.0 srpm for gnome-utils on linuxppc using glibc 2.1.94 and the Linux 2.4-test9 kernel I believe I have uncovered a flaw in the linux/fs.h header. Unless I apply a patch like below to linux/fs.h... --- fs.h.orgThu Sep 28 18:32:55 2000 +++ fs.hThu Sep 28 18:33:08 2000 @@ -20,7 +20,6 @@ #include #include #include -#include #include #include I find that the compile of gnome-utils fails as follows... gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../intl -DGLADEDIR=\""/usr/share/gfloppy/glade"\" -I/usr/include -DNEED_GNOMESUPPORT_H -I/usr/lib/gnome-libs/include -I/usr/lib/glib/include -I/usr/X11R6/include -I/usr/l In file included from /usr/include/linux/string.h:21, from /usr/include/linux/fs.h:23, from badblocks.c:43: this is because in the absence of ifdef __KERNEL__ wrapper on linux/string.h the following conflict occurs between extern int strncasecmp(const char *, const char *, int); from /usr/include/asm/string.h and extern int strncasecmp (__const char *__s1, __const char *__s2, size_t __n) __THROW __attribute_pure__; from /usr/include/string.h. This include for linux/string.h is not present in linux 2.2.x's linux/fs.h. Also removing it has no impact on compiling kernels in Linux 2.4-test9. Franz Sirl and myself can find no use for it in the linux/fs.h header. Thanks in advance for addressing this flaw. Jack Howarth -- -- Versions installed: (if some fields are empty or look -- unusual then possibly you have very old versions) Linux localhost.localdomain 2.4.0-test9 #16 Wed Sep 27 18:32:57 EDT 2000 ppc unknown Kernel modules 2.3.15 Gnu C 2.95.3 Gnu Make 3.79.1 Binutils 2.10.0.26 Linux C Library2.1.94 Dynamic linker ldd (GNU libc) 2.1.94 Procps 2.0.7 Mount 2.10m Net-tools 1.56 Console-tools 0.3.3 Sh-utils 2.0 Modules Loaded -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] enabling APIC and NMI watchdog on UP systems
On Fri, 29 Sep 2000, Keith Owens wrote:
> Using performance counter 1 for NMI conflicts with using the
> performance counters for tuning. IMHO it is better to default to NMI
> off for UP so we do not disturb people who are doing performance
> monitoring. [...]
the number of people experiencing hard lockups, and the importance of
debugging these (annoying) lockups IMO far outweighs the potential
inconvenience caused by having to disable the NMI oopser for performance
tuning.
> That then requires a mechanism for configuring the UP NMI and
> activating it on the fly, which complicates the code.
no.
> set_nmi_counter_local() has to be called after every NMI to reset the
oops - i *am* reprogramming the counter (i obviously tested wether the NMI
oopser works on a non-SMP P6 system, and checked the NMI counter in
/proc/interrupts), but it was left out of the patch by accident [forgot to
create a .orig file]. I've attached the -C3 patch.
Ingo
--- linux/include/asm-i386/apic.h.orig Thu Sep 28 05:18:49 2000
+++ linux/include/asm-i386/apic.h Thu Sep 28 05:29:14 2000
@@ -71,6 +71,7 @@
extern int verify_local_APIC (void);
extern void cache_APIC_registers (void);
extern void sync_Arb_IDs(void);
+extern int detect_init_APIC (void);
extern void setup_local_APIC (void);
extern void init_apic_mappings(void);
extern void smp_local_timer_interrupt(struct pt_regs * regs);
--- linux/include/asm-i386/msr.h.orig Thu Oct 7 10:17:09 1999
+++ linux/include/asm-i386/msr.hThu Sep 28 05:33:02 2000
@@ -30,3 +30,21 @@
: "=a" (low), "=d" (high) \
: "c" (counter))
+#define MCG_STATUS_MSR 0x17a
+#define MCG_CAP0x179
+#define MCG_CTL0x17b
+#define MC0_BASE 0x400
+#define MC0_CTL_OFFSET0x0
+#define MC0_STATUS_OFFSET 0x1
+#define MC0_ADDR_OFFSET 0x2
+#define MC0_MISC_OFFSET 0x3
+#define MC0_BANK_COUNT0x4
+#define DEBUGCTLMSR0x1d9
+#define LASTBRANCHFROMIP 0x1db
+#define LASTBRANCHTOIP 0x1dc
+#define LASTINTFROMIP 0x1dd
+#define LASTINTTOIP 0x1de
+#define PERFCTR00xc1
+#define PERFCTR10xc2
+#define EVNTSEL00x186
+#define EVNTSEL10x187
--- linux/include/asm-i386/processor.h.orig Thu Sep 28 06:39:06 2000
+++ linux/include/asm-i386/processor.h Thu Sep 28 06:39:27 2000
@@ -127,6 +127,8 @@
(boot_cpu_data.x86_capability & X86_FEATURE_FXSR)
#define cpu_has_xmm \
(boot_cpu_data.x86_capability & X86_FEATURE_XMM)
+#define cpu_has_apic \
+ (boot_cpu_data.x86_capability & X86_FEATURE_APIC)
extern char ignore_irq13;
--- linux/include/asm-i386/timex.h.orig Thu Sep 28 06:47:10 2000
+++ linux/include/asm-i386/timex.h Thu Sep 28 06:47:15 2000
@@ -45,4 +45,6 @@
#endif
}
+extern unsigned long cpu_khz;
+
#endif
--- linux/arch/i386/kernel/apic.c.orig Thu Sep 28 05:07:18 2000
+++ linux/arch/i386/kernel/apic.c Thu Sep 28 07:06:44 2000
@@ -84,15 +84,7 @@
void __init connect_bsp_APIC(void)
{
if (pic_mode) {
- /*
-* Do not trust the local APIC being empty at bootup.
-*/
- clear_local_APIC();
- /*
-* PIC mode, enable symmetric IO mode in the IMCR,
-* i.e. connect BSP's local APIC to INT and NMI lines.
-*/
- printk("leaving PIC mode, enabling symmetric IO mode.\n");
+ printk("leaving PIC mode, enabling APIC mode.\n");
outb(0x70, 0x22);
outb(0x01, 0x23);
}
@@ -107,7 +99,7 @@
* interrupts, including IPIs, won't work beyond
* this point! The only exception are INIT IPIs.
*/
- printk("disabling symmetric IO mode, entering PIC mode.\n");
+ printk("disabling APIC mode, entering PIC mode.\n");
outb(0x70, 0x22);
outb(0x00, 0x23);
}
@@ -201,12 +193,98 @@
| APIC_DM_INIT);
}
+/*
+ * Detect and enable local APICs on non-SMP boards.
+ * Original code written by Keir Fraser
+ */
+
+int detect_init_APIC (void)
+{
+ u32 h, l, dummy, features;
+
+ if (boot_cpu_data.x86 < 5) {
+ printk("No local APIC on pre-Pentium Intel processors\n");
+ return -1;
+ }
+
+ if (boot_cpu_data.x86 == 6) {
+ /*
+* Some BIOSes disable the local APIC in the APIC_BASE MSR.
+* This can only be done in software for PPro and above.
+*/
+ rdmsr(0x1b, l, h);
+ if (!(l & 0x800)) {
+ printk("Local APIC disabled by BIOS -- reenabling.\n");
+ l |= 0x800;
+ wrmsr(0x1b, l, h);
+
Re: Linux 2.2.18pre11
Alan Cox wrote: > > 2.2.18pre11 I should mention that using an almost-all-modularised config I get this for the last few pachlevels: depmod: *** Unresolved symbols in /lib/modules/2.2.18pre11/misc/rio.o depmod: gs_set_termios depmod: gs_chars_in_buffer depmod: gs_write depmod: gs_close depmod: gs_put_char depmod: gs_flush_chars depmod: gs_debug depmod: gs_hangup depmod: gs_stop depmod: gs_flush_buffer depmod: gs_init_port depmod: gs_write_room depmod: gs_start -- Eyal Lebedinsky ([EMAIL PROTECTED]) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] enabling APIC and NMI watchdog on UP systems
On Thu, 28 Sep 2000 21:19:29 +0200 (CEST),
Ingo Molnar <[EMAIL PROTECTED]> wrote:
>the attached patch (against test9-pre7) is a cleaned up version Keir
>Fraser's APIC-on-UP patch, and adds the enabling code of Keith Owens which
>programs P6 performance counter 0 as an NMI. (i simplified the code alot -
>there is no problem at all with getting NMIs from two sources, and it's
>not necessary to make it configurable.)
Using performance counter 1 for NMI conflicts with using the
performance counters for tuning. IMHO it is better to default to NMI
off for UP so we do not disturb people who are doing performance
monitoring. That then requires a mechanism for configuring the UP NMI
and activating it on the fly, which complicates the code.
AFAICT your patch will not generate local APIC NMIs fast enough. From
kdb v1.5-beta2.
int set_nmi_counter_local(void)
{
extern unsigned long cpu_khz;
if (!(boot_cpu_data.x86_capability & X86_FEATURE_APIC))
return(-EIO);
if (nmi_watchdog_source && nmi_watchdog_source != 1)
return(0); /* Not using local APIC */
return wrmsr_eio(PERFCTR1, -(cpu_khz/HZ*1000), 0);
}
set_nmi_counter_local() has to be called after every NMI to reset the
counter. Otherwise the counter is zero (it just overflowed) and will
not generate another NMI until it loops all the way round to 2**40
again. If you are going to reprogram PERFCTR1 for every NMI then you
do not want to do that unless PERFCTR1 really is the NMI source, again
it will conflict with real use of the performance counters so we need
to track the source and make it configurable.
I am basing this on Intel ia32 arch vol3, 24319202.pdf
15.6.2. Monitoring Counter Overflow
...
When interrupted by a counter overflow, the interrupt handler needs to
perform the following actions:
* Save the instruction pointer (EIP register), code-segment selector,
TSS segment selector, counter values and other relevant information
at the time of the interrupt.
* Reset the counter to its initial setting and return from the
interrupt.
If you tested a UP compile on an SMP box, you probably got NMI via the
IO-APIC which hides the lack of counter reset. I had to hack
smp_scan_config() to immediately return(0) so it would not pick up the
SMP config and not use the IO-APIC for NMI.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] enabling APIC and NMI watchdog on UP systems
On Fri, 29 Sep 2000, Udo A. Steinberg wrote: > Machine is an uniprocessor AMD Thunderbird on an Asus A7V mobo. hm, it will not work on class 6 AMD systems. I'll fix this. Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] enabling APIC and NMI watchdog on UP systems
Ingo Molnar wrote: > > the attached patch (against test9-pre7) is a cleaned up version Keir > Fraser's APIC-on-UP patch, and adds the enabling code of Keith Owens which > programs P6 performance counter 0 as an NMI. (i simplified the code alot - > there is no problem at all with getting NMIs from two sources, and it's > not necessary to make it configurable.) > > i'd like to hear about how this patch works for people - it works here on > SMP systems and on P6 systems. The watchdog is enabled unconditionally - > this should significantly help debugging lockups on UP systems as well! Hi Ingo et al, I've been giving the patch a try, however it hangs my machine during boot. Here's the important bits from console: Local APIC disabled by BIOS -- reenabling found and enabled local APIC! It then locks up in Calibrating delay loop... Machine is an uniprocessor AMD Thunderbird on an Asus A7V mobo. If you need additional info let me know. Cheers, Udo. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
linux-2.4.0-test9-pre7 Oops
ksymoops 2.3.4 on i686 2.4.0-test9. Options used
-V (default)
-k /proc/ksyms (default)
-l /proc/modules (default)
-o /lib/modules/2.4.0-test9/ (default)
-m /boot/System.map-2.4.0-test9 (specified)
Unable to handle kernel paging request at virtual address 0010
c012eca1
*pde =
Oops: 0002
CPU:0
EIP:0010:[]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00210246
eax: ebx: c3135920 ecx: c3135920 edx: 0010
esi: c31358c0 edi: c31359e0 ebp: c10549f4 esp: c1127f70
ds: 0018 es: 0018 ss: 0018
Process kswapd (pid: 2, stackpage=c1127000)
Stack: c01310d4 c3135920 c10549f4 c1054a10 02ac 01a3 0001
c01292a3 c10549f4 0004
c0129a7c 0004 c01d80d1
Call Trace: [] [] [] [] []
[]
Code: 89 02 c7 41 30 00 00 00 00 0f b7 41 0a 50 51 e8 0f ff ff ff
>>EIP; c012eca1 <__remove_from_queues+19/34> <=
Trace; c01310d4
Trace; c01292a3
Trace; c0129a7c
Trace; c01d80d1
Trace; c0129b49
Trace; c01089e4
Code; c012eca1 <__remove_from_queues+19/34>
<_EIP>:
Code; c012eca1 <__remove_from_queues+19/34> <=
0: 89 02 mov%eax,(%edx) <=
Code; c012eca3 <__remove_from_queues+1b/34>
2: c7 41 30 00 00 00 00 movl $0x0,0x30(%ecx)
Code; c012ecaa <__remove_from_queues+22/34>
9: 0f b7 41 0a movzwl 0xa(%ecx),%eax
Code; c012ecae <__remove_from_queues+26/34>
d: 50push %eax
Code; c012ecaf <__remove_from_queues+27/34>
e: 51push %ecx
Code; c012ecb0 <__remove_from_queues+28/34>
f: e8 0f ff ff ffcall ff23 <_EIP+0xff23> c012ebc4
<__remove_from_lru_list+0/68>
cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 5
model name : Pentium II (Deschutes)
stepping: 2
cpu MHz : 350.000802
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 pat pse36
mmx fxsr
bogomips: 699.60
cat /proc/meminfo
total:used:free: shared: buffers: cached:
Mem: 64135168 60022784 41123840 4259840 33619968
Swap: 131600384 2924544 128675840
MemTotal:62632 kB
MemFree: 4016 kB
MemShared: 0 kB
Buffers: 4160 kB
Cached: 32832 kB
Active: 36852 kB
Inact_dirty: 136 kB
Inact_clean: 0 kB
Inact_target:14040 kB
HighTotal: 0 kB
HighFree:0 kB
LowTotal:62632 kB
LowFree: 4016 kB
SwapTotal: 128516 kB
SwapFree: 125660 kB
If you need any more information let me know.
--
L1: khromy ;[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Removing boot text
> is nothing wrong). > > Anyone know how other than changing the kernel code? You need to change the initial kernel message logging level to be higher yes - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Removing boot text
On Thu, 28 Sep 2000, Paul Powell wrote: > We are using Linux as a bootable CD for system > configuration. We would like to keep all the > information displayed at bootup hidden. The main > reason for this is because our users see words such as > "error" and "failed" and it bothers them (though there > is nothing wrong). > > Anyone know how other than changing the kernel code? > > Thanks > The stuff that is written in the kernel by printk() can be configured to go to an RS-232C port. This has to be compiled into the kernel. You use append="console=ttyS0,BAUDRATE" in LILO configuration. This keeps it off the screen. The stuff written by init, can be eliminated by changing the link of /dev/console to point to /dev/null instead of /dev/tty0. Cheers, Dick Johnson Penguin : Linux version 2.2.15 on an i686 machine (797.90 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] Please read the FAQ at http://www.tux.org/lkml/
2.4.0-test9-pre7 oops (Unable to handle kernel paging request)
I tried booting 2.4.0-test9-pre7 today on my work machine for the first time, and it hung up when one of my user programs was started. The process "receiver_d" uses sockets and shared memory and has worked without problems for years with many kernel versions up through 2.4.0-test9-pre5. I did manage to get this program running after several attempts, so the oops doesn't occur every time. Here is a snippet from /var/log/messages: kernel: Unable to handle kernel paging request at virtual address d0b88ffc kernel: printing eip: kernel: c0190c30 kernel: *pde = 01454063 kernel: *pte = kernel: Oops: kernel: CPU:0 kernel: EIP:0010:[sys_shmat+204/636] kernel: EFLAGS: 00010246 kernel: eax: d0b89000 ebx: ecx: 01b6 edx: kernel: esi: edi: ebp: 0002 esp: cb50ff64 kernel: ds: 0018 es: 0018 ss: 0018 kernel: Process receiver_d (pid: 824, stackpage=cb50f000) kernel: Stack: b90c 0003 0001 3800 kernel: c010f65d cb50ffb4 cb50e000 kernel:b90c b910 0003 0022 c010a818 cb50ffc4 c010a6ef kernel: Call Trace: [sys_ipc+361/524] [error_code+44/52] [system_call+51/56] kernel: Code: 8b 04 90 85 c0 75 07 c6 05 64 49 2f c0 01 85 c0 0f 84 8a 01 kernel: NET: 32 messages suppressed. I won't be at my work email until Monday, but can be reached at [EMAIL PROTECTED] if anyone wants to cc any further questions. Thanks, Steven Cole - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.2.18pre11
> - Only 64 of 96 mbytes ram was found BIOS issue > - Trident 4DWave DX show those messages: trident: drain_dac, dma timeout? I've sene these a few times, they are harmless but I need to figure out why the tail clear code causes them > > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux kernel modules development in C++
** Reply to message from Horst von Brand <[EMAIL PROTECTED]> on Thu, 28 Sep 2000 16:44:55 -0400 > Right. And C++ was designed carefully along "you pay for what you use", so > with careful programming it should be no worse. OTOH, in C you _see_ the > costs [OK, maybe a hardened asm-fanatic will take issue with that...], in > C++ you don't necessarily see what is going on. I don't agree with that at all. C is not better or worse than C++ in this regard. The only way to truly know what you get is to examine the generated assembly code. When I do this, more often than not I'm surprised at how the compiler interpreted my code, or what code the compiler generated. The only time my C++ compiler generated code that I was wildly less efficient than I expected was when I created an lookup table of member functions. I had to rewrite the code to use a switch/case statement instead. -- Timur Tabi - [EMAIL PROTECTED] Interactive Silicon - http://www.interactivesi.com When replying to a mailing-list message, please don't cc: me, because then I'll just get two copies of the same message. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PIDs limited to 15 significant bits
On Fri, Sep 29, 2000 at 09:17:11AM +1200, Chris Wedgwood wrote: > [The patch is available. There are a few security advantages. > Also, it makes a fork a just measurable fraction of a percent > faster.] > > How does it make it faster? The only thing I can see is it might > remove the heuristic we have for when PIDs wrap -- which technically > we still need. Until the first wraparound has happened we need not check whether the pid is in use already as pid or pgid or sid. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[2.4.test9pre7] spontaneous reboot
Hi ! As I see recently on this list, I'm also experiencing spontaneous reboot here. This happen _twice_ with kernel 2.4.test9pre7 on my mostly idle and never overclocked K6 machine. It's so strange because this machine always run 2.4.x kernels with high load without any problems.. Unfortunately no syslog no oops just a silent reboot :( luca -- -- E-mail..: Luca Montecchiani <[EMAIL PROTECTED]> W.W.W...: http://i.am/m.luca - http://luca.myip.org Speakfreely.: sflwl -hlwl.fourmilab.ch luca@ I.C.Q...: 17655604 ---=(Linux since 1995)=--- Non esiste vento favorevole per il marinaio che non sa dove andare Seneca - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[PATCH] 2.2.x Isdn init function fix
Hi !
Init function for hisax driver cause a kernel hangup if the
idstring was omitted
"hisax=18,2" hang on boot
"hisax=18,2,HiSax" was fine
Kernel 2.4.x and modularized hisax was fine as well.
--- linux/drivers/isdn/hisax/config.c.orig Wed May 10 15:26:11 2000
+++ linux/drivers/isdn/hisax/config.c Thu Sep 28 22:48:44 2000
@@ -619,7 +619,7 @@
}
i++;
}
- if (strlen(str)) {
+ if (str) {
strcpy(HiSaxID, str);
HiSax_id = HiSaxID;
} else {
Grepping the whole kernel I also spot another possible place:
--- linux/drivers/isdn/icn/icn.c.orig Thu Sep 28 22:50:55 2000
+++ linux/drivers/isdn/icn/icn.cThu Sep 28 22:51:13 2000
@@ -1869,7 +1869,7 @@
portbase = ints[1];
if (ints[0] > 1)
membase = ints[2];
- if (strlen(str)) {
+ if (str) {
strcpy(sid, str);
icn_id = sid;
if ((p = strchr(sid, ','))) {
--
--
E-mail..: Luca Montecchiani <[EMAIL PROTECTED]>
W.W.W...: http://i.am/m.luca - http://luca.myip.org
Speakfreely.: sflwl -hlwl.fourmilab.ch luca@
I.C.Q...: 17655604
---=(Linux since 1995)=---
Non esiste vento favorevole per il marinaio che non sa dove andare
Seneca
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.2.18pre11
Some problems here.. - Only 64 of 96 mbytes ram was found - Trident 4DWave DX show those messages: trident: drain_dac, dma timeout? I'll provide more info/testing on request, luca ver_linux: -- Linux luca.home.net 2.2.18pre11 #8 Wed Sep 27 22:27:35 CEST 2000 i586 unknown Kernel modules 2.3.14 Gnu C egcs-2.91.66 Binutils 2.9.5.0.16 Linux C Library2.1.2 Dynamic linker ldd (GNU libc) 2.1.2 Linux C++ Library 2.9.0 Procps 2.0.6 Mount 2.10m Net-tools 1.53 Kbd0.99 Sh-utils 1.16 Modules Loaded hisax isdn slhc .config: CONFIG_EXPERIMENTAL=y CONFIG_M586TSC=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_TSC=y CONFIG_1GB=y CONFIG_MTRR=y CONFIG_MODULES=y CONFIG_NET=y CONFIG_PCI=y CONFIG_PCI_GOANY=y CONFIG_PCI_BIOS=y CONFIG_PCI_DIRECT=y CONFIG_PCI_QUIRKS=y CONFIG_PCI_OLD_PROC=y CONFIG_SYSVIPC=y CONFIG_SYSCTL=y CONFIG_BINFMT_AOUT=y CONFIG_BINFMT_ELF=y CONFIG_BINFMT_MISC=y CONFIG_PARPORT=y CONFIG_PARPORT_PC=y CONFIG_APM=y CONFIG_BLK_DEV_FD=y CONFIG_BLK_DEV_IDE=y CONFIG_BLK_DEV_IDEDISK=y CONFIG_BLK_DEV_IDECD=y CONFIG_BLK_DEV_IDESCSI=y CONFIG_BLK_DEV_IDEPCI=y CONFIG_BLK_DEV_IDEDMA=y CONFIG_IDEDMA_AUTO=y CONFIG_BLK_DEV_ALI15X3=y CONFIG_BLK_DEV_LOOP=y CONFIG_PARIDE_PARPORT=y CONFIG_PACKET=y CONFIG_UNIX=y CONFIG_INET=y CONFIG_SKB_LARGE=y CONFIG_SCSI=y CONFIG_CHR_DEV_SG=y CONFIG_NETDEVICES=y CONFIG_DUMMY=m CONFIG_ISDN=m CONFIG_ISDN_PPP=y CONFIG_ISDN_PPP_VJ=y CONFIG_ISDN_MPP=y CONFIG_ISDN_DRV_HISAX=m CONFIG_HISAX_EURO=y CONFIG_HISAX_ELSA=y CONFIG_VT=y CONFIG_VT_CONSOLE=y CONFIG_SERIAL=y CONFIG_UNIX98_PTYS=y CONFIG_UNIX98_PTY_COUNT=256 CONFIG_PRINTER=y CONFIG_MOUSE=y CONFIG_PSMOUSE=y CONFIG_JOYSTICK=y CONFIG_JOY_PCI=y CONFIG_NVRAM=y CONFIG_RTC=y CONFIG_AGP=y CONFIG_AGP_ALI=y CONFIG_FAT_FS=y CONFIG_MSDOS_FS=y CONFIG_VFAT_FS=y CONFIG_ISO9660_FS=y CONFIG_JOLIET=y CONFIG_PROC_FS=y CONFIG_DEVPTS_FS=y CONFIG_EXT2_FS=y CONFIG_NLS=y CONFIG_NLS_DEFAULT="cp437" CONFIG_NLS_CODEPAGE_850=y CONFIG_VGA_CONSOLE=y CONFIG_VIDEO_SELECT=y CONFIG_SOUND=y CONFIG_SOUND_TRIDENT=y CONFIG_MAGIC_SYSRQ=y dmesg: -- Linux version 2.2.18pre11 ([EMAIL PROTECTED]) (gcc version egcs-2.91.66 19990314 (egcs-1.1.2 release)) #8 Wed Sep 27 22:27:35 CEST 2000 Detected 451004 kHz processor. ide_setup: hdd=ide-scsi Console: colour VGA+ 80x25 Calibrating delay loop... 901.12 BogoMIPS Memory: 64260k/66496k available (912k kernel code, 412k reserved, 860k data, 52k init) Dentry hash table entries: 16384 (order 5, 128k) Buffer cache hash table entries: 65536 (order 6, 256k) Page cache hash table entries: 16384 (order 4, 64k) CPU: L1 I Cache: 32K L1 D Cache: 32K CPU: AMD-K6(tm) 3D processor stepping 0c Checking 386/387 coupling... OK, FPU using exception 16 error reporting. Checking 'hlt' instruction... OK. POSIX conformance testing by UNIFIX mtrr: v1.35a (19990819) Richard Gooch ([EMAIL PROTECTED]) PCI: PCI BIOS revision 2.10 entry at 0xfb4e0 PCI: Using configuration type 1 PCI: Probing PCI hardware Linux agpgart interface v0.99 (c) Jeff Hartmann agpgart: Maximum main memory to use for agp memory: 28M agpgart: Detected Ali M1541 chipset agpgart: AGP aperture is 64M @ 0xd000 Linux NET4.0 for Linux 2.2 Based upon Swansea University Computer Society NET3.039 NET4: Unix domain sockets 1.0 for Linux NET4.0. NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP TCP: Hash tables configured (ehash 65536 bhash 65536) Starting kswapd v 1.5 parport0: PC-style at 0x378 [SPP] Detected PS/2 Mouse Port. Serial driver version 4.27 with no serial options enabled ttyS00 at 0x03f8 (irq = 4) is a 16550A ttyS01 at 0x02f8 (irq = 3) is a 16550A pty: 256 Unix98 ptys configured lp0: using parport0 (polling). Real Time Clock Driver v1.09 Non-volatile memory driver v1.0 Trident 4DWave/SiS 7018/Ali 5451 PCI Audio, version 0.14.6a, 21:56:02 Sep 27 2000 trident: Trident 4DWave DX found at IO 0xec00, IRQ 9 ac97_codec: AC97 Audio codec, vendor id1: 0x8384, id2: 0x7605 (SigmaTel STAC9704) js: Joystick driver v1.2.15 (c) 1999 Vojtech Pavlik <[EMAIL PROTECTED]> js0: Analog 2-axis 4-button joystick on Trident 4DWave DX #0 loop: registered device at major 7 ALI15X3: IDE controller on PCI bus 00 dev 78 ALI15X3: not 100% native mode: will probe irqs later ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:DMA, hdb:DMA *ALi IDE driver (1.0 beta3)* * Chip Revision is 20* * Maximum capability is - DMA * ide1: BM-DMA at 0xf008-0xf00f, BIOS settings: hdc:DMA, hdd:DMA hda: IBM-DJNA-371350, ATA DISK drive hdb: ASUS CD-S340, ATAPI CDROM drive hdc: Maxtor 84320D4, ATA DISK drive hdd: PCRW404, ATAPI CDROM drive ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 ide1 at 0x170-0x177,0x376 on irq 15 ALI15X3: MultiWord DMA enabled hda: IBM-DJNA-371350, 12949MB w/1966kB Cac
Re: [patch] enabling APIC and NMI watchdog on UP systems
On Fri, 29 Sep 2000, Miles Lane wrote: > Cool. Is there anything else I need to know in order to the > UP-NMI-oopser effectively? It sounds like it'll just force an OOPS to > occur where a deadlock might have occured in the past. Is this > correct? If so, then using it is easy and I'll just see if I can get > my machines to crash. yes, it's merged into the IOAPIC based NMI oopser. Usage is completely automatic - it will oops if a hard lockup has occured. (ie. if a processor does not server interrupts for more than 5 seconds.) I have tested this by artificially causing kernel lockups, and it works here as expected. so it's a simple 'apply, compile, reboot' thing. Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux kernel modules development in C++
Ragnar Hojland Espinosa <[EMAIL PROTECTED]> said: > On Thu, Sep 28, 2000 at 01:45:40AM +0200, Igmar Palsenberg wrote: [...] > > - The're a lot more people that know C than C++ > Let's put it the other way... there aren't many people who know C++ > around. Well, there are less people who understand the kernel. Then, > maybe, to make it more accessible, we should dumb it down. It is not necessarily a good thing that everybody and her grandmother think they can hack on Linux... exhibit A for the defense: Look at the average skill level of your run-of-the-mill $GUI_WORDPROCESSOR user: Sure, they are able to write a memo, and are "experts"; but make that a 20-page document, and then use a different printer: Awful. This is exactly what Linus meant when he said he doesn't want an in-kernel debugger: Dumb it down, and you select dumber hackers, and the result is a mess. [...] > Someone mentioned they preferred C because they knew exactly what the > compiler would be generating. I wonder if they got this knowledge in some > magic way, and what makes them think that they couldn't learn what C++ > compilers do (at least G++) Right. And C++ was designed carefully along "you pay for what you use", so with careful programming it should be no worse. OTOH, in C you _see_ the costs [OK, maybe a hardened asm-fanatic will take issue with that...], in C++ you don't necessarily see what is going on. But that is part of learning C++ well, I guess. > Of course, yes, I do agree that if the kernel is in C and putting in C++ > requires more than some little localized glue or similar, C++ shouldn't go > in. Right. > But I'll never understand this C++ aversion. When Linux started, there was _no_ decent freeware C++ compiler around. g++'s C++ was a bad joke, the compiler was very unstable, and C++ (the language) changed almost weekly. Only recently (with egcs, essentially) did the C++ support in GCC become respectable, and the language stabilized. But by that time the kernel source corpus was firmly locked into (GCC's) C for better or worse. -- Dr. Horst H. von Brand mailto:[EMAIL PROTECTED] Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, ChileFax: +56 32 797513 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PIDs limited to 15 significant bits
On Wed, Sep 27, 2000 at 02:32:17PM +0100, Bernhard Bender wrote: > looking at my process list after a week or so of uptime I discoverd that PIDs > seem to wrap around at 32767 (aka. 2^15 - 1). Yes. > I find this "feature" annoying, since I like to view my process list sorted > by PID, which gives a nice overview about recently started processes vs. > age-old daemons. > > So, I would like to ask if someone could please explain the reason for this. > If there is no compelling reason I would like to propose to remove this > limit. I recall this was not present in 2.2.x You recall incorrectly. The code is old. There is very little reason for it, and we could change today. In fact I think I once submitted the corresponding patch. My machines regularly see 6- or 7-digit PIDs. There are two very minor points: (i) If you are in the habit of tar'ing up /proc, and moreover the tar you use considers files with the same device and inode to be identical, then your tarfiles may become smaller after the patch -#define fake_ino(pid,ino) (((pid)<<16)|(ino)) +#define fake_ino(pid,ino) (((1)<<16)|(ino)) in fs/proc/base.c. (ii) There is also a rather obscure place in SYSV IPC where a 16-bit pid_t is used for the fields msg_lspid and msg_lrpid of the (obsolete) struct msqid_ds and the fields shm_cpid and shm_lpid of the (obsolete) struct shmid_ds. Nothing compiled today uses this, and almost nothing uses it at all, but this nevertheless means that one needs an option CONFIG_15BIT_PID (default=N) for backward binary compatibility. Andries [The patch is available. There are a few security advantages. Also, it makes a fork a just measurable fraction of a percent faster.] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] enabling APIC and NMI watchdog on UP systems
Ingo Molnar wrote: > if SysRq works then this is a 'soft lockup', and if you want to debug this > then you should capture the EIP values from RightAlt+ScrLk output, thats > the place where it locks up. The UP-NMI-oopser will not help. > > Ingo Cool. Is there anything else I need to know in order to the UP-NMI-oopser effectively? It sounds like it'll just force an OOPS to occur where a deadlock might have occured in the past. Is this correct? If so, then using it is easy and I'll just see if I can get my machines to crash. Miles - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] enabling APIC and NMI watchdog on UP systems
Ingo, Can you please outline exactly what testers with UP machines need to do to build, set up, enable and debug using this new code? I have an Athlon 750MHz machine and a Pentium II laptop that I use for testing and I'd like to exercise some of the experimental VM code. I have gotten system deadlocks on both of these machines, but I need some pointers in how best to extract useful debugging information from the deadlocked systems. Any help you can give in this regard would be much appreciated. I have used SysRq successfully, but I don't know how to use the information I am given to find the salient points. Thanks, Miles - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] enabling APIC and NMI watchdog on UP systems
On Fri, 29 Sep 2000, Miles Lane wrote: > how best to extract useful debugging information from the deadlocked > systems. Any help you can give in this regard would be much > appreciated. I have used SysRq successfully, but I don't know how to > use the information I am given to find the salient points. if SysRq works then this is a 'soft lockup', and if you want to debug this then you should capture the EIP values from RightAlt+ScrLk output, thats the place where it locks up. The UP-NMI-oopser will not help. Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Posting to this list without 500 bounces?
In article <3776575819.970144217@[10.10.1.2]>, Martin J. Bligh <[EMAIL PROTECTED]> wrote: >> When I was researching the use of ORBS and MAPS a few weeks >> back, my first thought was that the DUL would unfairly block Linux >> users running Sendmail. Looks like that's true. > >Just give sendmail a smart_host of your ISP's mail server. In theory >I guess this slows thing down, and yes it's a pain, but on the other >hand, it works. It speeds things up in a lot of cases. What if the destination host is down? What if the destination host is in Zimbabwe connected through a 9600 baud modem? Much easier to transfer your mail full speed to the ISPs smarthost and let it care about all that. And unreliable ISP SMTP servers? Hard to imagine, as 99.5% of the userbase undoubtedly uses that SMTP server and I can't believe that a reasonable ISP randomly drops email messages. That being said you should never get bounces when posting to the Linux kernel mailing list, since it isn't you who delivers all that mail to the endusers, but the majordomo running on vger or one of the exploders. The SMTP envelope from address should also be set to majordomo@vger, so I can't see how you would get hundreds of ORBS and DUL bounces ... &^%*& fscking out-of-office replies, yes (they should reinstate hanging for that ...) Mike. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.18 megaraid driver broken [was: Re: Linux 2.2.18pre11]
In article <8qvfae$j52$[EMAIL PROTECTED]>, Miquel van Smoorenburg <[EMAIL PROTECTED]> wrote: >In article <[EMAIL PROTECTED]>, >Alan Cox <[EMAIL PROTECTED]> wrote: >>2.2.18pre11 >[..] >>o Fix inia100/megaraid define clash (Arjan van de Ven) >[..] > >The megaraid driver in 2.2.18 doesn't work with MegaRaid 434 cards. Note that it wasn't 2.2.18pre11 that broke megaraid. The first 2.2.18pre kernel I tried was 2.2.18pre5 which already had this problem (see <[EMAIL PROTECTED]> posted on Tue, 12 Sep 2000 14:10:56 +0200) Mike. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Can ext3 or ReiserFS w/ journalling be made on /dev/loop?
Hi out there!
I was asked a question lately that I was unable to answer: Assume you
want to make a (encrypted, but that's not the issue here) filesystem on
a loopback block device (/dev/loop*). Can this be a journalling one? In
other words, will
prompt$ mount -t {ext3|reiserfs} -oloop my_file my_mount_point
be stable to work with?
TIA,
Marc
--
Marc Mutz <[EMAIL PROTECTED]>http://marc.mutz.com/Encryption-HOWTO/
University of Bielefeld, Dep. of Mathematics / Dep. of Physics
PGP-keyID's: 0xd46ce9ab (RSA), 0x7ae55b9e (DSS/DH)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
2.4.0-test8 and PDC 20265
Hi all, I am trying very hard to get kernel 2.4.0-test8 to recognize the Promise Ultra66 PCI IDE add-on card -- based on PDC 20265. The motherboard is a FIC SD-11 (Athlon 700). The only other PCI card is a D-link quad ethernet card (DFE-570TX). The kernel correctly recognizes the card as a PDC-20265, but the drives on the controller are not recognized. The drive is a standard IBM 4.3 G IDE drive. The card is in PCI Slot-1 (next to the AGP slot). The award BIOS doesn't recognize the card. I dont' see anything in the BIOS boot messages that say "Promise Ultra66". The odd thing is that, the motherboard won't boot unless I disable the BIOS interrupts for the addon card -- this is an option in one of the award BIOS setup screens. The rest of the box is a clean install of SuSE 6.4. The following messages are from Linux startup: === dmesg === mtrr: v1.36 (2221) Richard Gooch ([EMAIL PROTECTED]) PCI: PCI BIOS revision 2.10 entry at 0xfdb01, last bus=2 PCI: Using configuration type 1 PCI: Probing PCI hardware PCI: Using IRQ router VIA [1106/0586] at 00:07.0 Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP IP: routing cache hash table of 512 buckets, 4Kbytes TCP: Hash tables configured (established 8192 bind 8192) Starting kswapd v1.7 pty: 256 Unix98 ptys configured Uniform Multi-Platform E-IDE driver Revision: 6.31 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx PDC20262: IDE controller on PCI bus 00 dev 18 PDC20262: device not capable of full native PCI mode PDC20262: device disabled (BIOS) VP_IDE: IDE controller on PCI bus 00 dev 39 VP_IDE: chipset revision 6 VP_IDE: not 100% native mode: will probe irqs later VP_IDE: VIA vt82c686a IDE UDMA66 controller on pci0:7.1 ide0: BM-DMA at 0xffa0-0xffa7, BIOS settings: hda:DMA, hdb:DMA ide1: BM-DMA at 0xffa8-0xffaf, BIOS settings: hdc:pio, hdd:pio hda: WDC WD64AA, ATA DISK drive hdb: WDC WD64AA, ATA DISK drive ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx hdc: Maxtor 91361U3, ATA DISK drive hdd: CREATIVE CDROM CD5232E, ATAPI CDROM drive ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 ide1 at 0x170-0x177,0x376 on irq 15 hda: 12594960 sectors (6449 MB) w/2048KiB Cache, CHS=784/255/63, UDMA(33) hdb: 12594960 sectors (6449 MB) w/2048KiB Cache, CHS=784/255/63, UDMA(33) hdc: 26588016 sectors (13613 MB) w/512KiB Cache, CHS=26377/16/63, UDMA(33) Partition check: hda: hda1 hda2 hda3 hda4 < hda5 hda6 > hdb: hdb1 hdb2 hdc: [PTBL] [1655/255/63] hdc1 Floppy drive(s): fd0 is 1.44M FDC 0 is a post-1991 82077 Serial driver version 5.02 (2000-08-09) with MANY_PORTS SHARE_IRQ SERIAL_PCI enabled ttyS00 at 0x03f8 (irq = 4) is a 16550A Real Time Clock Driver v1.10c Linux Tulip driver version 0.9.10 (September 6, 2000) eth0: Digital DS21143 Tulip rev 65 at 0xbc00, 00:80:C8:CA:A7:69, IRQ 9. eth0: EEPROM default media type Autosense. eth0: Index #0 - Media MII (#11) described by a 21142 MII PHY (3) block. eth0: MII transceiver #1 config 3100 status 7869 advertising 01e1. eth1: Digital DS21143 Tulip rev 65 at 0xb800, 00:80:C8:CA:A7:6A, IRQ 11. eth1: EEPROM default media type Autosense. eth1: Index #0 - Media MII (#11) described by a 21142 MII PHY (3) block. eth1: MII transceiver #1 config 3100 status 7849 advertising 01e1. eth2: Digital DS21143 Tulip rev 65 at 0xb400, 00:80:C8:CA:A7:6B, IRQ 5. eth2: EEPROM default media type Autosense. eth2: Index #0 - Media MII (#11) described by a 21142 MII PHY (3) block. eth2: MII transceiver #1 config 3100 status 7849 advertising 01e1. eth3: Digital DS21143 Tulip rev 65 at 0xb000, 00:80:C8:CA:A7:6C, IRQ 10. eth3: EEPROM default media type Autosense. eth3: Index #0 - Media MII (#11) described by a 21142 MII PHY (3) block. eth3: MII transceiver #1 config 3100 status 7849 advertising 01e1. Linux agpgart interface v0.99 (c) Jeff Hartmann agpgart: Maximum main memory to use for agp memory: 94M agpgart: Detected AMD Irongate chipset agpgart: AGP aperture is 512M @ 0xc000 [drm] AGP 0.99 on AMD Irongate @ 0xc000 512MB [drm] Initialized tdfx 1.0.0 2719 on minor 63 kmem_create: Forcing size word alignment - nfs_fh = end dmesg === This is from /proc/ioports: -001f : dma1 0020-003f : pic1 0040-005f : timer 0060-006f : keyboard 0070-007f : rtc 0080-008f : dma page reg 00a0-00bf : pic2 00c0-00df : dma2 00f0-00ff : fpu 0170-0177 : ide1 01f0-01f7 : ide0 0376-0376 : ide1 03c0-03df : vga+ 03f6-03f6 : ide0 03f8-03ff : serial(auto) 0400-040f : VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] 0cf8-0cff : PCI conf1 1170-1177 : Promise Technology, Inc. 20262 11f0-11f7 : Promise Technology, Inc. 20262 1374-1377 : Promise Technology, Inc. 20262 13f4-13f7 : Promise Technology, Inc. 20262 5000-50ff : VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] 6000-607f : VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] 6800-683f : Promise T
RE: SSE instructions
Hello,
2.4.0-test1 and higher. make sure you select PIII as the CPU in the config.
Best Wishes,
Lyle
--
Which version of the kernel is needed in order to run the following
program on an PIII?
void main()
{
__asm__ __volatile__("xorps %%xmm0, %%xmm1" ::: "memory");
}
astor
--
Alexander KjeldaasMail: [EMAIL PROTECTED]
finger [EMAIL PROTECTED] for OpenPGP key.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
_
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.
Share information about yourself, create your own public profile at
http://profiles.msn.com.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Removing boot text
We are using Linux as a bootable CD for system configuration. We would like to keep all the information displayed at bootup hidden. The main reason for this is because our users see words such as "error" and "failed" and it bothers them (though there is nothing wrong). Anyone know how other than changing the kernel code? Thanks __ Do You Yahoo!? Yahoo! Photos - 35mm Quality Prints, Now Get 15 Free! http://photos.yahoo.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Posting to this list without 500 bounces?
> > When I was researching the use of ORBS and MAPS a few weeks > > back, my first thought was that the DUL would unfairly block Linux > > users running Sendmail. Looks like that's true. > > Just give sendmail a smart_host of your ISP's mail server. In theory > I guess this slows thing down, and yes it's a pain, but on the other > hand, it works. Unless your ISP's mailservers are unreliable. In which case, you have problems. Taking the "so, change your ISP" line isn't acceptable, and neither are ISP's mailservers being ORBed themselves. It doesn't discriminate against people using Sendmail on Linux; it discriminates against anybody who runs their own mail server because they MIGHT JUST have more competence than the people who run their ISP's servers. While the original blacklist I agree with and support wholeheartedly, the DUL list a pathetic attempt at reducing spam, and has cost users _FAR_ more time and money in trying to work around it in order to send legitimate mail than could possibly have been saved by preventing the spam that originates from dialup IPs. Instead of doing this, ISPs should start configuring their mail servers properly and close those damned open relays. THAT is who MAPS should be putting pressure on, not the innocent end-users. My serveral cents, Mo [who is now praying that his ISP's mail server has decided to work today :P] -- Mo McKinlay Chief Software Architect inter/open Labs - GnuPG Key: pub 1024D/76A275F9 2000-07-22 Mo McKinlay <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Posting to this list without 500 bounces?
On Thu, 28 Sep 2000, Phil Randal wrote: > When I was researching the use of ORBS and MAPS a few weeks > back, my first thought was that the DUL would unfairly block Linux > users running Sendmail. Looks like that's true. > The DUL's rationale is very suspect. The logic goes... Some > spammers use SMTP from their dial-up PCs to send spam, so we'll > block their ISP's dial-up address ranges. Not to worry, because > legitimate users will relay through their ISP's mail servers. You forgot about the lusers with open relays on hands. MAPS and ORBS can't handle that. And yes, it's serious - scanning the large range for open relays is trivial. Unfortunately, it scales well and spamware doing exactly that exists and is used. 30 56K links => T1... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: 2.2.18pre11
> Kernel segfaults on boot with MTRRs enabled. > Kernel locks system hard. Requires hardware reset > Recompiling without MTRR support eliminates problem. I broke cyrix support - wait for pre12 Sorry about that - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Posting to this list without 500 bounces?
> When I was researching the use of ORBS and MAPS a few weeks > back, my first thought was that the DUL would unfairly block Linux > users running Sendmail. Looks like that's true. Just give sendmail a smart_host of your ISP's mail server. In theory I guess this slows thing down, and yes it's a pain, but on the other hand, it works. Martin. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.2.18pre11
On Thu, Sep 28, 2000 at 10:14:14AM -0700, Dunlap, Randy wrote: > > On Thu, Sep 28, 2000 at 09:39:22AM -0700, Dunlap, Randy wrote: > > > > > > Yes, that looks like 2.4.0-test9 now, except that it should > > > be done for ohci also, although you don't need it for your > > > config. > > > > Right, but it doesn't look like the usb-ohci driver uses > > initcalls like > > the other functions. I could be wrong, new at kernel hacking. :-) > > > > -Dave > > - > > Ack, you're correct...but it should. 8;) It should, and will. ohci.c was a harder beast to backport, as it is using a lot of stuff that is 2.4.x specific. I'll finish it soon. thanks, greg k-h -- greg@(kroah|wirex).com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.2.18pre11
On Thu, Sep 28, 2000 at 09:07:46AM -0700, David Rees wrote: > On Thu, Sep 28, 2000 at 04:13:24AM -0500, Jeff Garzik wrote: > > > > On Thu, 28 Sep 2000, Arjan van de Ven wrote: > > > > > In article <[EMAIL PROTECTED]> you wrote: > > > > I'm getting this compile time error on 2.2.18pre11: > > > > > > > drivers/usb/usbdrv.o: In function `usb_init': > > > > drivers/usb/usbdrv.o(.text+0x6deb): undefined reference to `uhci_init' > > > > > > The patch below should fix that. > > > > No it doesn't read the usb/uhci code. It uses initcalls. The > > solution is to remove call to uhci_init() in usb_init(). > > Ah, is this the correct fix, then? I actually booted this one (I never > booted the other patch, just compiled it, and it works for me. :-) Yes, this is the correct fix. Sorry about that, I was going to add this patch when I converted ohci.c to the new driver, and hadn't gotten to that one yet. thanks, greg k-h -- greg@(kroah|wirex).com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Posting to this list without 500 bounces?
> I had the same problem; the DUL people said there had been people spamming > from my ISP, so they blocked _every_ user from that ISP (which is quite big) > I found very annoying that it just took a Joe Spammer to rip me from my > right to run sendmail on my PC. Funny, huh? > > So I switched ISPs and hope it takes a while to happen again. :| When I was researching the use of ORBS and MAPS a few weeks back, my first thought was that the DUL would unfairly block Linux users running Sendmail. Looks like that's true. The DUL's rationale is very suspect. The logic goes... Some spammers use SMTP from their dial-up PCs to send spam, so we'll block their ISP's dial-up address ranges. Not to worry, because legitimate users will relay through their ISP's mail servers. H. Dodgy. Phil Phil Randal Home: [EMAIL PROTECTED] Worcester, UK http://www.rebee.clara.net - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[patch] enabling APIC and NMI watchdog on UP systems
the attached patch (against test9-pre7) is a cleaned up version Keir
Fraser's APIC-on-UP patch, and adds the enabling code of Keith Owens which
programs P6 performance counter 0 as an NMI. (i simplified the code alot -
there is no problem at all with getting NMIs from two sources, and it's
not necessary to make it configurable.)
i'd like to hear about how this patch works for people - it works here on
SMP systems and on P6 systems. The watchdog is enabled unconditionally -
this should significantly help debugging lockups on UP systems as well!
(thanks Keir and Keith!)
Ingo
--- linux/include/asm-i386/apic.h.orig Thu Sep 28 05:18:49 2000
+++ linux/include/asm-i386/apic.h Thu Sep 28 05:29:14 2000
@@ -71,6 +71,7 @@
extern int verify_local_APIC (void);
extern void cache_APIC_registers (void);
extern void sync_Arb_IDs(void);
+extern int detect_init_APIC (void);
extern void setup_local_APIC (void);
extern void init_apic_mappings(void);
extern void smp_local_timer_interrupt(struct pt_regs * regs);
--- linux/include/asm-i386/msr.h.orig Thu Oct 7 10:17:09 1999
+++ linux/include/asm-i386/msr.hThu Sep 28 05:33:02 2000
@@ -30,3 +30,21 @@
: "=a" (low), "=d" (high) \
: "c" (counter))
+#define MCG_STATUS_MSR 0x17a
+#define MCG_CAP0x179
+#define MCG_CTL0x17b
+#define MC0_BASE 0x400
+#define MC0_CTL_OFFSET0x0
+#define MC0_STATUS_OFFSET 0x1
+#define MC0_ADDR_OFFSET 0x2
+#define MC0_MISC_OFFSET 0x3
+#define MC0_BANK_COUNT0x4
+#define DEBUGCTLMSR0x1d9
+#define LASTBRANCHFROMIP 0x1db
+#define LASTBRANCHTOIP 0x1dc
+#define LASTINTFROMIP 0x1dd
+#define LASTINTTOIP 0x1de
+#define PERFCTR00xc1
+#define PERFCTR10xc2
+#define EVNTSEL00x186
+#define EVNTSEL10x187
--- linux/include/asm-i386/processor.h.orig Thu Sep 28 06:39:06 2000
+++ linux/include/asm-i386/processor.h Thu Sep 28 06:39:27 2000
@@ -127,6 +127,8 @@
(boot_cpu_data.x86_capability & X86_FEATURE_FXSR)
#define cpu_has_xmm \
(boot_cpu_data.x86_capability & X86_FEATURE_XMM)
+#define cpu_has_apic \
+ (boot_cpu_data.x86_capability & X86_FEATURE_APIC)
extern char ignore_irq13;
--- linux/include/asm-i386/timex.h.orig Thu Sep 28 06:47:10 2000
+++ linux/include/asm-i386/timex.h Thu Sep 28 06:47:15 2000
@@ -45,4 +45,6 @@
#endif
}
+extern unsigned long cpu_khz;
+
#endif
--- linux/arch/i386/kernel/apic.c.orig Thu Sep 28 05:07:18 2000
+++ linux/arch/i386/kernel/apic.c Thu Sep 28 07:06:44 2000
@@ -84,15 +84,7 @@
void __init connect_bsp_APIC(void)
{
if (pic_mode) {
- /*
-* Do not trust the local APIC being empty at bootup.
-*/
- clear_local_APIC();
- /*
-* PIC mode, enable symmetric IO mode in the IMCR,
-* i.e. connect BSP's local APIC to INT and NMI lines.
-*/
- printk("leaving PIC mode, enabling symmetric IO mode.\n");
+ printk("leaving PIC mode, enabling APIC mode.\n");
outb(0x70, 0x22);
outb(0x01, 0x23);
}
@@ -107,7 +99,7 @@
* interrupts, including IPIs, won't work beyond
* this point! The only exception are INIT IPIs.
*/
- printk("disabling symmetric IO mode, entering PIC mode.\n");
+ printk("disabling APIC mode, entering PIC mode.\n");
outb(0x70, 0x22);
outb(0x00, 0x23);
}
@@ -201,12 +193,98 @@
| APIC_DM_INIT);
}
+/*
+ * Detect and enable local APICs on non-SMP boards.
+ * Original code written by Keir Fraser
+ */
+
+int detect_init_APIC (void)
+{
+ u32 h, l, dummy, features;
+
+ if (boot_cpu_data.x86 < 5) {
+ printk("No local APIC on pre-Pentium Intel processors\n");
+ return -1;
+ }
+
+ if (boot_cpu_data.x86 == 6) {
+ /*
+* Some BIOSes disable the local APIC in the APIC_BASE MSR.
+* This can only be done in software for PPro and above.
+*/
+ rdmsr(0x1b, l, h);
+ if (!(l & 0x800)) {
+ printk("Local APIC disabled by BIOS -- reenabling.\n");
+ l |= 0x800;
+ wrmsr(0x1b, l, h);
+
+ /*
+* The APIC feature bit should now be enabled
+* in `cpuid'
+*/
+ cpuid(1, &dummy, &dummy, &dummy, &features);
+ if (!(features & X86_FEATURE_APIC)) {
+ printk("Could not enable APIC!\n");
PROBLEM: 2.2.18pre11
Kernel segfaults on boot with MTRRs enabled. Kernel locks system hard. Requires hardware reset Recompiling without MTRR support eliminates problem. /proc/version Linux version 2.2.18pre11 (root@shockwave) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #6 Wed Sep 27 15:25:03 EDT 2000 ver_linux -- Versions installed: (if some fields are empty or looks -- unusual then possibly you have very old versions) Linux shockwave 2.2.18pre11 #6 Wed Sep 27 15:25:03 EDT 2000 i686 unknown Kernel modules 2.3.11 Gnu C egcs-2.91.66 Binutils 2.9.1.0.25 Linux C Library2.1.3 Dynamic linker ldd: version 1.9.9 Procps 2.0.6 Mount 2.10l Net-tools 1.55 Kbd0.99 Sh-utils 2.0 Modules Loaded bsd_comp ppp slhc old_tulip ip_masq_raudio ip_masq_portfw ip_masq_ftp ip_masq_autofw /proc/cpuinfo processor : 0 vendor_id : CyrixInstead cpu family : 6 model : 2 model name : M II 3x Core/Bus Clock stepping: 8 cpu MHz : 224.881 fdiv_bug: no hlt_bug : no sep_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu de tsc msr cx8 mtrr pge cmov mmx bogomips: 448.92 /proc/modules bsd_comp3888 0 (autoclean) ppp20140 2 (autoclean) [bsd_comp] slhc4448 1 (autoclean) [ppp] old_tulip 25464 1 (autoclean) ip_masq_raudio 3000 0 (unused) ip_masq_portfw 2564 2 ip_masq_ftp 2648 0 (unused) ip_masq_autofw 2516 0 (unused) /proc/scsi/scsi Attached devices: Host: scsi0 Channel: 00 Id: 00 Lun: 00 Vendor: SEAGATE Model: ST51080N Rev: 0943 Type: Direct-AccessANSI SCSI revision: 02 Host: scsi0 Channel: 00 Id: 03 Lun: 00 Vendor: iomega Model: jaz 1GB Rev: H.72 Type: Direct-AccessANSI SCSI revision: 02 Host: scsi0 Channel: 00 Id: 05 Lun: 00 Vendor: SONY Model: CD-ROM CDU-76S Rev: 1.1c Type: CD-ROM ANSI SCSI revision: 02 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux kernel modules development in C++
** Reply to message from Martin Dalecki <[EMAIL PROTECTED]> on Thu, 28 Sep 2000 20:31:05 +0200 > Simple: The fact that G++ is constantly changing what it's generatign > even > between minor numbers: > > 1. Calling conventions. > 2. Name mungling. > 3. Construct semantics. > 4. Run time support (stdio and STL). > 5. New features here and there... > > and so on and so on... Binary compatibility in C++ was NEVER an option, on any platform. The C++ standard specifically excludes any definition for the binary layout of classes and calling conventions. Anyone who writes "modules" (e.g. DLLs, drivers, whatever) knows that you can't have cross-module C++ calls. Everything must be translated to C calls with a standard calling convention (typically the Pascal calling convention on Windows and OS/2). -- Timur Tabi - [EMAIL PROTECTED] Interactive Silicon - http://www.interactivesi.com When replying to a mailing-list message, please don't cc: me, because then I'll just get two copies of the same message. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Posting to this list without 500 bounces?
On Wed, Sep 27, 2000 at 05:38:23PM -0400, Mike A. Harris wrote: > This message may be seen by some to be OT, but it concerns > ISP's SMTP. I figured despite the slowness, it would solve the > problem. Now I'm getting back all sorts of bounces from machines > blocking using something at "www.mail-abuse.org/dul" which > appears at a glance to be some list of all ISP's dialup modems or > something - meaning using my dialup machine with my own MTA is > going to be just as bad or worse.. SIGH. I had the same problem; the DUL people said there had been people spamming from my ISP, so they blocked _every_ user from that ISP (which is quite big) I found very annoying that it just took a Joe Spammer to rip me from my right to run sendmail on my PC. Funny, huh? So I switched ISPs and hope it takes a while to happen again. :| -- /| Ragnar Højland Freedom - Linux - OpenGL Fingerprint 94C4B \ o.O| 2F0D27DE025BE2302C =(_)= "Thou shalt not follow the NULL pointer for 104B78C56 B72F0822 U chaos and madness await thee at its end." hkp://keys.pgp.com Handle via comment channels only. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux kernel modules development in C++
Ragnar Hojland Espinosa wrote: > > On Thu, Sep 28, 2000 at 01:45:40AM +0200, Igmar Palsenberg wrote: > > Some arguments why not to use it in the kernel : > > > > - C++ gives overhead. With something like a kernel that's unwanted. > > You pay for what you use, no less no more. C++ compilers don't generate > bloated code `per se' but, yes, it's easier to make mistakes that degenerate > into bloatedness. > > > - Things like exception handling is hard to do in a kernel. > > You don't need it. And if you don't use it you don't pay for it. > > > - The're a lot more people that know C than C++ > > Let's put it the other way... there aren't many people who know > C++ around. Well, there are less people who understand the kernel. Then, > maybe, to make it more accessible, we should dumb it down. > > > And I probably forgot a few :) > > Sure :) > > Someone mentioned they preferred C because they knew exactly what the > compiler would be generating. I wonder if they got this knowledge in some > magic way, and what makes them think that they couldn't learn what C++ > compilers do (at least G++) Simple: The fact that G++ is constantly changing what it's generatign even between minor numbers: 1. Calling conventions. 2. Name mungling. 3. Construct semantics. 4. Run time support (stdio and STL). 5. New features here and there... and so on and so on... You just can't follow them all in case you are not interrested in becoming a compiler developer yourself! And then there are tons of hidden code generation there: 1. Constructors/Destructors 2. Templates 3. Operator overloding - which can be very successfully used to hide the true semantic of the operators from the code reader. In esp. copy contructors and such... 4. Hidden inheritance due to header mess... 5. Sic and fragile semantics of all language components! > Of course, yes, I do agree that if the kernel is in C and putting in C++ > requires more than some little localized glue or similar, C++ shouldn't go > in. > > But I'll never understand this C++ aversion. C++ is fine for GUI coding and such but it's no good in case you really need full controll of the underlying machine - and the only way to get this is to have full controll of what's generated by the compiler. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [CFT][PATCH] ext2 directories in pagecache
On Thu, 28 Sep 2000, Andreas Dilger wrote:
> This would also explain why the direntry offset is pointing past the
> end of the first dir block, because the next block was added at the time
> the new file was created, but then later lost.
Nope. Try the following:
@@ -378,12 +378,13 @@
de = (struct ext2_dir_entry_2 *) ((char *) de + rec_len);
}
}
-
- if (chunk_offs == 0) {
+ chunk_offs += chunk_size;
+ if (chunk_offs == PAGE_CACHE_SIZE) {
unsigned long index = page->index+1;
ext2_put_page(page);
page = grab_cache_page(dir->i_mapping, index);
kmap(page);
+ chunk_offs = 0;
}
err = page->mapping->a_ops->prepare_write(NULL, page, chunk_offs,
chunk_offs+chunk_size);
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
Re: [CFT][PATCH] ext2 directories in pagecache
Marco writes: > On Thu, Sep 28, 2000 at 11:51:02AM -0400, Alexander Viro wrote: > > On Thu, 28 Sep 2000, Marko Kreen wrote: > > > On Tue, Sep 26, 2000 at 05:29:27PM -0400, Alexander Viro wrote: > > > > > > EXT2-fs error (device sd(8,6)): ext2_add_entry: bad entry in directory > > > #28699: rec_len is smaller than minimal - offset=1024, inode=0, > > > rec_len=0, name_len=0 > > > > BTW, did fsck complain about that directory? > > > It seemed not, all errors were for unattached inodes... > When creating a new database PostgreSQL creates new dir under > /var/lib/postgres/data/base and that did not succeed after fsck too. It may be that the next block in the directory is not being written to disk. Any inodes created in a directory, whose direntries are in the second block will be "unattached" at fsck time if the second dir block is not written to disk, because no directory is referencing these inodes. This would also explain why the direntry offset is pointing past the end of the first dir block, because the next block was added at the time the new file was created, but then later lost. 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 - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED]
RE: Russell King forks ARM Linux.
On Thu, 28 Sep 2000 10:58:35 -0700, Howell, David P wrote: > My 2 cents. > > I don't read this mail list for this type of rubbish either. The technical > detail of this thread is all that seems appropriate here, not the issue > between George and Russell. I'd be embarrassed if I were either of them, > the way that they have presented themselves, don't they or their > organizations > have better stuff to do (I do)? Please stop this thread, the war is over. The communication problem is solved, I just got everybody involved in the original thread on arm-linux-kernel talking to each other again. We are currently working on a solution and working out the technical details. Erik -- J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department of Electrical Engineering, Faculty of Information Technology and Systems, Delft University of Technology, PO BOX 5031, 2600 GA Delft, The Netherlands Phone: +31-15-2783635 Fax: +31-15-2781843 Email: [EMAIL PROTECTED] WWW: http://www-ict.its.tudelft.nl/~erik/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux kernel modules development in C++
On Thu, Sep 28, 2000 at 01:45:40AM +0200, Igmar Palsenberg wrote: > Some arguments why not to use it in the kernel : > > - C++ gives overhead. With something like a kernel that's unwanted. You pay for what you use, no less no more. C++ compilers don't generate bloated code `per se' but, yes, it's easier to make mistakes that degenerate into bloatedness. > - Things like exception handling is hard to do in a kernel. You don't need it. And if you don't use it you don't pay for it. > - The're a lot more people that know C than C++ Let's put it the other way... there aren't many people who know C++ around. Well, there are less people who understand the kernel. Then, maybe, to make it more accessible, we should dumb it down. > And I probably forgot a few :) Sure :) Someone mentioned they preferred C because they knew exactly what the compiler would be generating. I wonder if they got this knowledge in some magic way, and what makes them think that they couldn't learn what C++ compilers do (at least G++) Of course, yes, I do agree that if the kernel is in C and putting in C++ requires more than some little localized glue or similar, C++ shouldn't go in. But I'll never understand this C++ aversion. -- /| Ragnar Højland Freedom - Linux - OpenGL Fingerprint 94C4B \ o.O| 2F0D27DE025BE2302C =(_)= "Thou shalt not follow the NULL pointer for 104B78C56 B72F0822 U chaos and madness await thee at its end." hkp://keys.pgp.com Handle via comment channels only. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Russell King forks ARM Linux.
Howell, David P writes: > I don't read this mail list for this type of rubbish either. The technical > detail of this thread is all that seems appropriate here, not the issue > between George and Russell. I'd be embarrassed if I were either of them, > the way that they have presented themselves, don't they or their > organizations have better stuff to do (I do)? > > And I agree with Miles on this procedurally, was wondering when it would be > said. And my 2 pence worth: I would ask people who do not know all the facts not to comment on this. Your comments are meaningless or even worse wrong if you are not in possession of the full facts. If you have replied to the mails that appeared here, then you are not in full posession of the facts, and your mail is meaningless. Thank you. _ |_| - ---+---+- | | Russell King[EMAIL PROTECTED] --- --- | | | | http://www.arm.linux.org.uk/personal/aboutme.html / / | | +-+-+ --- -+- / | THE developer of ARM Linux |+| /|\ / | | | --- | +-+-+ - /\\\ | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: Russell King forks ARM Linux.
My 2 cents. I don't read this mail list for this type of rubbish either. The technical detail of this thread is all that seems appropriate here, not the issue between George and Russell. I'd be embarrassed if I were either of them, the way that they have presented themselves, don't they or their organizations have better stuff to do (I do)? And I agree with Miles on this procedurally, was wondering when it would be said. Dave Howell -Original Message- From: Miles Lane [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 28, 2000 8:36 AM To: George France Cc: Linux Kernel Subject: Re: Russell King forks ARM Linux. Well, this sucks. I am not sure how you both came to this impass, but it really is quite unacceptable. I think there are several problems here: No maintainer should cut off contribution from an entire company to a platform it intends to help support and implement. Usually these kinds of impasses are a result of limited thinking on the part of both parties. You and the contributors within Compaq/DEC should extend an olive branch of some sort and try to focus on technical solutions that will work for everyone, including the maintainer. It seems to me that if the conflict has been over architecture for serial devices, you could simply agree to pursue different paths for a while and see how that pans out. I know of several places in the Linus kernel where this is being done -- the HCDs in the new USB support and the experimental VMs. Specifically, there are two UHCI HCDs: usb-uhci and uhci. They were written by different people and share no code. They should both, however, be completely compatible with one another, since they are endeavoring to support the same specification. This has been blessed by Randy Dunlap for the time being. I believe there will come a time when one of the UHCI HCDs will be dropped, but in the meantime, both provide good exprimental feedback. Perhaps you and Russell could agree on such a path. The bottom line is that I think you should be looking at your contributions with a long view and think creatively about how to avoid conflict with Russell. On the other hand, I'm not sure what the process is regarding the selection of a maintainer, but it seems to me that remaining open to contribution is a requirement for a maintainer. Perhaps the Linux community should draft up some guidelines for the job of maintainer that would include some mechanism for replacing a maintainer who is not effectively shepherding his port. Miles George France wrote: > Greetings; > > As you probably know Russell King is the maintainer of ARM Linux. Him and I > have been debating how serial ports should be handled on an off for months > now. IMHO, today he lost it, declaring that he was going to block all > e-mails from Compaq, which means he can not recieve any more ARM Linux > patches from us. I have tried every method that I know of, to work with > him, but he has cut off all commutations. So starting tomorrow, we will be > submitting patches directly to the kernel mailing list, since Russell will > not even receive our e-mails. I will also be setting up an ARM mailing list > and web pages, for those that wish to participate. It is too bad that > Russell has decided to create a fork in the ARM Linux tree. It is his > choice. > > Attached is his e-mail for the curious. > > Best Regards, > > > --George > > George France, [EMAIL PROTECTED] > Cambridge Research Laboratory, Compaq Computer Corporation > One CambridgecenterMS: CRL > Cambridge, MA 02142 USA > > > >> Since this issue raises your blood pressure to an explosive level, I will >> not bother you again. I can handle this without you. > > And thus you shall. I shall not be accepting anything further from you. > Call this what you will, but you have brought this on yourself and your > organisation. I am NOT going to work with incompetent selfish people who > refuse to listen to reason. > > Good luck, we'll benefit without your uninformed arguments. > > From this point on, I shall be blocking you and your companies email > addresses. > I don't want to hear from you ever again. You're not worth the bandwidth > you > waste. > > Appologies in advance to anyone at the old crl.dec.com domain who can listen > to reason, I've had enough of this shit. >_ > |_| - ---+---+- > | |Russell King [EMAIL PROTECTED] --- --- > | | | |http://www.arm.linux.org.uk// / | > | +-+-+ --- -+- > / | THE developer of ARM Linux |+| /|\ > / | | | --- | > +-+-+ - /\\\ | > > ___ > http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm-k
Re: Promise PDC20295 support?
On Thu, 28 Sep 2000, Lars Gaarden wrote: > Hi. > > Is anyone working on support for the Promise PDC20295 > ATA100 chip? Are you sure it is not the PDC20265? > If not, does anyone know if specs are available from > Promise? > > -- > LarsG > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ > Andre Hedrick The Linux ATA/IDE guy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux kernel modules development in C++
Daniel Phillips <[EMAIL PROTECTED]> said: [...] > Well, I *like* using // for one line comments, and I *hate* having my > code obfuscated with extra declaration lines just because I can't > declare something in the middle of a block. Those are rather weak reasons for selecting one language over the other. > There is no reason whatever > to hang on to such stupid limitations in C in the mistaken belief that > it somehow keeps it more pure. If I'm not mistaken, both are in C99 (yes, gcc doesn't comply yet). No huge outcry I've heard... OTOH, it is (sadly) true that people bicker bitterly over trivial aspects of their choosen languages (i.e., comment format, or where you can declare new stuff) and never even consider the areas of _real_ differences. > On the other hand, I hate bloat even > more than I hate those other two things. At least a step forward. > On the third hand, the first > feature is already in every known C compiler // comments are in gcc; definitions wherever you like aren't. > (but you will be pecked to > death by a flock of penguins if you use it) and the second feature > actually represents a simplification of the compiler code, It gets more complicated to do one-pass compilation, as you have to collect the definitions that affect the current frame by looking at the whole block first. True, the difference is trivial or nonexistent with current compiler technology, but it was important in K&R days. >which in case > anyone doesn't know uses the same code generator and most of the same > parser whether you write in C or C++ - so I don't know where all those > arguments about relative efficiency of generated code are coming from. The parsers for C and C++ in gcc are completely different. C and C++ happen to look alike as long as you don't stray from the C subset of C++ (no wonder, C++ was designed that way), but the full languages are utterly different. C is rather easy to parse, C++ is a nightmare. Sure, if I'd have to start writing a C/C++ compiler today, I'd think of arranging for a common parser just to save some work. > The way to get C++ into the kernel is to get some of the less invasive > features of C++ into C. This process started a long time ago and will > never stop. Gosh, even if you are a C++ hater you are probably already > using a bagfull of C++ features. It's called ANSI C, aka C89 (const, prototypes, void *), and now C99. But is goes the other way much more, and OO-people hate C++'s guts because of what it inherited from C ;-) -- Dr. Horst H. von Brand mailto:[EMAIL PROTECTED] Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, ChileFax: +56 32 797513 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
driver compatible on 2.0.x to 2.2.x kernels
Hi all, I am developing a driver for a crypto card... and i need this driver to run on different kernel versions say 2.0.x to 2.2.x... how do i do that or is it better not to support backward kernels like 2.0 any help appreciated... thanks in advance azad - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Compiling Ricky Beam's patched dpt_i2o.c into the kernel in2.4.0.0-21
Thanks Ricky, that's a great help! Nick. On Thu, 28 Sep 2000, Ricky Beam wrote: > On Thu, 28 Sep 2000, Nick Loman wrote: > >I'm trying to compile in Ricky Beam's patched dpt_i2o.c file (for DPT > >SmartRAID V support) into the kernel. I got it working as a module, but > >now I want it compiled directly in. > > I run with it compiled in (I boot from the SR-V.) > > I've put diffs for 2.4.0-test5 and 2.4.0-test7 up. That's exactly what I'm > running. The .config (config.cramer) is in there for reference. > > >The problem I have is that at link stage (make bzImage) it is complaining > >about undefined references to many simple functions such as printk() and > >sprintf(). > > This is a configuration mismatch. It's looking for versioned symbols. > Do you have module versioning enabled? Did you rerun "make dep" after > changing from a module to built-in? > > --Ricky > > > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Compiling Ricky Beam's patched dpt_i2o.c into the kernel in2.4.0.0-21
On Thu, 28 Sep 2000, Nick Loman wrote: >I'm trying to compile in Ricky Beam's patched dpt_i2o.c file (for DPT >SmartRAID V support) into the kernel. I got it working as a module, but >now I want it compiled directly in. I run with it compiled in (I boot from the SR-V.) I've put diffs for 2.4.0-test5 and 2.4.0-test7 up. That's exactly what I'm running. The .config (config.cramer) is in there for reference. >The problem I have is that at link stage (make bzImage) it is complaining >about undefined references to many simple functions such as printk() and >sprintf(). This is a configuration mismatch. It's looking for versioned symbols. Do you have module versioning enabled? Did you rerun "make dep" after changing from a module to built-in? --Ricky - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [DOC] Debugging early kernel hangs
> If a kernel hangs early in the boot process (before the console has
> been initialized) then printk is no use because you never see the
> output. There is a technique for using the video display to indicate
> boot progress so you can localize the problem. Reporting "my kernel
> hangs during boot at line nnn in routine xyz" is a lot better than "my
> kernel hangs during boot".
I was doing some similar debug work, and stole some code from the
early boot decompress stuff, and munged it. It's a nasty hack that only
works on x86 (probably), and hardcodes video addresses, etc. But you
might find it useful to print out addresses, etc with.
There are routines to print things, scroll the screen, clear the screen,
and spin for a specified number of seconds (so that you can actually
read the output ;-) )
Martin.
/* Martin J. Bligh <[EMAIL PROTECTED]> */
#define VIDMEMBUF 0xB800
int orig_x = 0;
int orig_y = 0;
int vidport = 0x3d4;
void early_scroll(void)
{
int i, cols = 80, lines = 25;
unsigned char *vidmem = phys_to_virt(VIDMEMBUF);
memcpy ( vidmem, vidmem + cols * 2, ( lines - 1 ) * cols * 2 );
for ( i = ( lines - 1 ) * cols * 2; i < lines * cols * 2; i += 2 )
vidmem[i] = ' ';
}
void clearvidmem(void)
{
int x, y, pos = 0;
unsigned char *vidmem = phys_to_virt(VIDMEMBUF);
for (x = 0; x < 80; x++) {
for (y = 0; y < 25; y++) {
vidmem [ ( x + 80 * y ) * 2 ] = ' ';
}
}
orig_x = 0;
orig_y = 0;
/* Update cursor position */
outb_p(14, vidport);
outb_p(0xff & (pos >> 9), vidport+1);
outb_p(15, vidport);
outb_p(0xff & (pos >> 1), vidport+1);
}
void pokevidmem(int x, int y, char c)
{
unsigned char *vidmem = phys_to_virt(VIDMEMBUF);
vidmem [ ( x + 80 * y ) * 2 ] = c;
}
void spin_on_me(int howlong)
{
int i, j;
for (i=0; i= lines ) {
early_scroll();
y--;
}
} else {
pokevidmem (x, y, c);
if ( ++x >= cols ) {
x = 0;
if ( ++y >= lines ) {
early_scroll();
y--;
}
}
}
}
orig_x = x;
orig_y = y;
pos = (x + cols * y) * 2; /* Update cursor position */
outb_p(14, vidport);
outb_p(0xff & (pos >> 9), vidport+1);
outb_p(15, vidport);
outb_p(0xff & (pos >> 1), vidport+1);
}
void early_printk(const char *fmt, ...)
{
va_list args;
int i;
char buf[1024];
va_start(args, fmt);
i = vsprintf(buf, fmt, args); /* hopefully i < sizeof(buf)-4 */
va_end(args);
early_puts(buf);
printk(buf);
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
RE: Linux 2.2.18pre11
> On Thu, Sep 28, 2000 at 09:39:22AM -0700, Dunlap, Randy wrote: > > > > Yes, that looks like 2.4.0-test9 now, except that it should > > be done for ohci also, although you don't need it for your > > config. > > Right, but it doesn't look like the usb-ohci driver uses > initcalls like > the other functions. I could be wrong, new at kernel hacking. :-) > > -Dave > - Ack, you're correct...but it should. 8;) ~Randy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Russell King forks ARM Linux.u
From: "H. Peter Anvin" <[EMAIL PROTECTED]> > Does that mean SPARC has a conflict between the 8250/16x50 driver and the > Zilog driver? If so, the latter should probably move (ttyZ is still an > unused name.) If there's a conflict it would be with the minor numbers, which I haven't been able to check yet, not the /dev namespace. Well, if if both drivers want their users to use ttyS0 as the first UART from each, the user will have to pick one, but that's not up to the driver. ..Stu - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
kernel panic
Hi there... One of my teachers (a linux newbie) got the following kernel panic with a pre-compiled redhat 6.2 standard kernel: Kernel panic: Attempted to kill idle task! In swapper task - not syncing with friendly regards jens luedicke <[EMAIL PROTECTED]> Support the Theory of Evolution; 400 Billion Amphibians can't be wrong! Q: What is the difference between Texas and yogurt? A: Yogurt has culture. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.2.18pre11
On Thu, Sep 28, 2000 at 09:39:22AM -0700, Dunlap, Randy wrote: > > Yes, that looks like 2.4.0-test9 now, except that it should > be done for ohci also, although you don't need it for your > config. Right, but it doesn't look like the usb-ohci driver uses initcalls like the other functions. I could be wrong, new at kernel hacking. :-) -Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux kernel modules development in C++
On Thu, 28 Sep 2000, Igmar Palsenberg wrote: > To bad I don't have time to get the basic kernel code.. Would be a good > investment in time I guess. > > I assume the above struct holds pointers to the essential function > calls, with a NULL value if the're not overridden (defaults) ? See include/linux/mm.h. The structure contains pointer to methods table (->vm_ops). Yup, garden-variety virtual table pointer. grep for vm_ops and vm_operations_struct to see how it's used annd what it is. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Russell King forks ARM Linux.u
Stuart MacDonald wrote: > > From: "Alan Cox" <[EMAIL PROTECTED]> > > > The only thing I'm not sure is that I believe the SPARC people uses > > > ttyS* for Zilog 8530-based serial ports. I don't know if we want to > > > define this as NS8250-family serial ports in light of that; I more > > > tended to think of it as the "default" serial port for the > > > architecture. > > > > What happens when you plug a PCI 16x50 card into a PCI bus sparc nowdays ? > > It should just work like i386, with ttyS*, but we haven't yet got > a sparc box to check. > Does that mean SPARC has a conflict between the 8250/16x50 driver and the Zilog driver? If so, the latter should probably move (ttyZ is still an unused name.) -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] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux kernel modules development in C++
> Oh, I understand why #2 is necessary, that doesn't mean that I don't hear > people complain about it anyway. On a side note, I consider lack of a real > kernel debugger to be evidence for #1. But I don't want to kick that dead > horse again. Well, I'm one of those guys who never uses debuggers :) > > I'd be a bit more careful. It is in large part those "completely > > ridiculous, nobody will ever be able to write decent software that way" > > whims that got Linux to where it stands today. > > Very true! Regards, Igmar - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
sleeping funkifies network in 2.4.0-test8
After waking up my machine from a sleep, the network goes in fits and starts. Any network connections will pause for a bit, then flow for a bit, and so on. The network card is Tulip-based (either a d-link or linksys) in an Athlon box running standard RH6.2 with apmd. A reboot is necessary to restore the network functionality. -- Robert Dale Digital Mission - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: Linux 2.2.18pre11
> > > In article <[EMAIL PROTECTED]> you wrote: > > > > I'm getting this compile time error on 2.2.18pre11: > > > > > > > drivers/usb/usbdrv.o: In function `usb_init': > > > > drivers/usb/usbdrv.o(.text+0x6deb): undefined reference > to `uhci_init' > > > > > > The patch below should fix that. > > > > No it doesn't read the usb/uhci code. It uses initcalls. The > > solution is to remove call to uhci_init() in usb_init(). > > Ah, is this the correct fix, then? I actually booted this > one (I never > booted the other patch, just compiled it, and it works for me. :-) > > -Dave > > --- linux/drivers/usb/usb-core.c.orig Thu Sep 28 08:44:59 2000 > +++ linux/drivers/usb/usb-core.cThu Sep 28 08:47:13 2000 > @@ -60,12 +60,6 @@ > usb_hub_init(); > > #ifndef CONFIG_USB_MODULE > -#ifdef CONFIG_USB_UHCI > - uhci_init(); > -#endif > -#ifdef CONFIG_USB_UHCI_ALT > - uhci_init(); > -#endif > #ifdef CONFIG_USB_OHCI > ohci_hcd_init(); > #endif > > - Yes, that looks like 2.4.0-test9 now, except that it should be done for ohci also, although you don't need it for your config. ~Randy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: pcmcia cd-writer
On Thu, 28 Sep 2000, Richard Polton wrote: > I have been advised that PCMCIA cd-writers are not supported by Linux. > Is this true and > if so, will they be? That strongly depends on what type of interface is used by the PCMCIA card. By definition a complete CD writer will not fit into a PCMCIA slot ;) So an interface is in use. There are several adapter cards for PCMCIA. I for example have a PCMCIA SCSI card which would attach to a pretty standard SCSI CD writer. This again should then work if the PCMCIA SCSI card is supported (as a side note: there are several PCMCIA SCSI cards supported by the pcmcia-cs package). If the card implements another interface you might be lucky. So on the bottomline you will have to check what type of interface your PCMCIA CD writer uses and if _this_ is supported. > Thanks, > Richard CU nils faerber -- kernel concepts Engel & Faerber GbR Tel: +49-271-771091-12 Dreisbachstr. 24 Fax: +49-271-771091-19 D-57250 Netphen D1 : +49-170-2729106 -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux kernel modules development in C++
> > Tell my teacher it's a good idea, he is telling otherwise :) > >Teaching people to UNDERSTAND and THINK in OO methods can help >in several problems. There is no absolute requirement that >final implementations are done in any sort of OO languages. > >.. any language with structures, data- and function pointers >is trivially yieldable to do OO things. > >All it takes is to have some discipline, and a way of thinking >to make object oriented C. (Without templates, and exceptions >perhaps, but object anyway.) > > >Most people seem to think that having syntactic sugar coating >everything is a must for an OO language. I don't feel so, but >I begun with USCD p-system Pascal, continued with CLU(ster), >and finally learned C. > >Of those, CLU is full of sugar, all ideas that are presented >as "new" in C++ I have exploited in CLU back in late 1980es. >(And I mean *all*, exceptions and templates included!) >(But back then I used 36 bit mainframes by Digital..) Agree. Using a OO design can make think a lot easier. I'm mostly using plain C because that what I'm used to. Igmar - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux kernel modules development in C++
On Thu, 28 Sep 2000, Igmar Palsenberg wrote: > On Wed, 27 Sep 2000, Alexander Viro wrote: > > > > OO is indeed != C++. But since it's a relative if C, it's the most > > > suitable option to use in the kernel. > > > > What's wrong with C itself? > > Nothing. What I was saying if you want some OO language in the kernel, C++ > is the only option I guess. Mixing languages is a pain.. There is no such thing as "OO language". There is OO style and there are ways to use it when you are writing in almost any language. And OO in C is not harder than OO in C++, provided that you are not trying to write in C++ and translate line-by-line into C. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux kernel modules development in C++
> Just remember what another, quite famous, teacher told Linus about failing > him for the monolithic design of Linux if he took his OS class. Then look > around and search for the ukernel OSes he predicted would be ubiquitous > very soon afterwards... > > Don't believe what teachers say. Code speaks. To bad my teacher thinks otherwise.. Het still requires I code using Hongarian notation.. And I really hate it.. Igmar - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
