Re: Abysmal RECV network performance
Hi, I'm guessing that the tulip driver is not setting the chip up correctly. I've seen this happen with other tulip variants (21143) when tries to autonegotiate. if you do an ifconfig eth1 you will see numerous carrier and crc errors. Set the tulip_debug flag to 2 or 3 in /etc/modules.conf and see what gets said. A newer version of the driver may help you. You might try the one on sourceforge. Also, I've only ever seen full 100BaseT speeds with decent adapters, like 21143 based tulips, Intel eepros, and vortex/boomerang 3com cards. A lot of the cheaper controllers just won't get there. skd On Mon, May 28, 2001 at 03:47:22AM +, John William wrote: > Can someone please help me troubleshoot this problem - I am getting abysmal > (see numbers below) network performance on my system, but the poor > performance seems limited to receiving data. Transmission is OK. > > The computer in question is a dual Pentium 90 machine. The machine has > RedHat 7.0 (kernel 2.2.16-22 from RedHat). I have compiled 2.2.19 (stock) > and 2.4.3 (stock) for the machine and used those for testing. I had a > NetGear FA310TX card that I used with the "tulip" driver and a 3Com 3CSOHO > card (Hurricane chipset) that I used with the "3c59x" driver. I used the > netperf package to test performance (latest version, but I don't have the > version number off-hand). The numbers netperf is giving me seem to correlate > well to FTP statistics I see to the box. > > I have a second machine (P2-350) with a NetGear FA311 (running 2.4.3 and the > "natsemi" driver) that I used to talk with the Pentium 90 machine. The two > machines are connected through a NetGear FS105 10/100 switch. I also tried > using a 10BT hub (see below). > > When connected, the switch indicated 100 Mbps, full duplex connections to > both cards. This matches the speed indicator lights on both cards. I have > run the miidiag program in the past to verify that the cards are actually > set to full duplex, but I didn't run it again this time (this isn't the > first time I have tried to chase this problem down). > > For the purposes of this message, call the P2-350 machine "A" and the dual > P-90 machine "B". I ran the following tests: > > Machine "A" to localhost 754.74 Mbps > > Kernel 2.2.19SMP > Machine "B" to localhost 80.63 Mbps > Machine "B" to "A" (tulip)55.38 Mbps > Machine "A" to "B" (tulip)10.60 Mbps > Machine "A" to "B" (3c95x)12.10 Mbps > > Kernel 2.4.3 SMP > Machine "B" to localhost 83.87 Mbps > Machine "B" to "A" (tulip)68.07 Mbps > Machine "A" to "B" (tulip)1.62Mbps > Machine "A" to "B" (3c95x)2.37Mbps > > Kernel 2.2.16-22 (RedHat kernel) > Machine "B" to localhost 92.29 Mbps > Machine "B" to "A" (tulip)57.34 Mbps > Machine "A" to "B" (tulip)9.98Mbps > Machine "A" to "B" (3c95x)9.05Mbps > > Now, with both "A" and "B" plugged into a 10BT hub: > > Kernel 2.2.19SMP > Machine "B" to "A" (tulip)6.96Mbps > Machine "A" to "B" (tulip)6.89Mbps > > At the end of the runs, I do not see any messages in syslog that would > indicate a problem. Using the switch, there were no collisions but looking > at /sbin/ifconfig there were a lot of "Frame:" errors on receive. "A lot" > means ~30% of the total packets received. This happened with both cards and > all kernels. > > The conclusions I draw from this data are: > > 1) Both machines connecting to localhost (data not going out over the wire) > give reasonable numbers and are considerably above what I actually see going > over the network (as would be expected). > 2) The P-90 machine seems to have good transmit speed over both cards and > all kernels. Transmit performance is close to the localhost numbers, so I > can believe them. In the past, I have compared the performance of the FA310 > to the 3ComSOHO card and there did not seem to be any measurable performance > difference between the two. > 3) Both the FA310 and the 3ComSOHO card have similar receive speeds, leading > me to believe that the problem lies with either the machine or the kernel > and not the individual cards or drivers. > 4) Booting the machine as a uni-processor machine (with a non-SMP 2.2.16 > kernel) did not change anything, so it does not appear to be a problem with > SMP. > 5) Kernel 2.4.3 receive performance is significantly lower than either 2.2.x > kernel, so that tends to point to some fundamental problem in the kernel. > 6) As I understand it, the 3Com card has some hardware acceleration for > checksumming, and this is a slow machine, so why is the performance almost > identical to the FA310? > > So, my questions are: > > What kind of performance should I be seeing with a P-90 on a 100Mbps > connection? I was expecting something in the range of 40-70 Mbps - certainly > not 1-2 Mbps. > > What can I do to track this problem down? Has anyone else had problems like > this? > > Thanks in advance
[PATCH] CSLIP compiled as module in 2.4.[345]
Hello List, The attached patch should fix the missing symbols in SLIP with CSLIP support, if compiled as module. It applies cleanly against 2.4.3 but should work with 2.4.5 too. Regards, Michael Guntsche slip.patch
Re: interrupt problem with MPS 1.4 / not with MPS 1.1 ?
Looking at the diff of "lspci -vvvxxx" between MPS1.1 and MPS1.4 (on the same system) may be quite useful... maybe I missed the earlier "lspci -vvvxxx", but I only see one here... -- Jeff Garzik | Disbelief, that's why you fail. Building 1024| MandrakeSoft | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [CHECKER] 2.4.5-ac4 security holes
On Thu, May 31, 2001 at 09:49:14PM -0700, Dawson Engler wrote: > - > [BUG] fixed in ac5, I believe. > /u2/engler/mc/oses/linux/2.4.5-ac4/drivers/usb/bluetooth.c:438:bluetooth_write: >ERROR:PARAM:461:438: Deref tainted var 'buf' (tainted from line 461) Yes it is. greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: interrupt problem with MPS 1.4 / not with MPS 1.1 ?
On Thu, May 31, 2001 at 10:45:17PM +0200, Manfred Spraul wrote: > [EMAIL PROTECTED] wrote: > > > > 00:07.2 USB Controller: VIA Technologies, Inc. UHCI USB (rev 16) (prog-if 00 >[UHCI]) > > Subsystem: Unknown device 0925:1234 > > Flags: bus master, medium devsel, latency 32, IRQ 5 > > I/O ports at a000 [size=32] > > Capabilities: [80] Power Management version 2 > > 30: 00 00 00 00 80 00 00 00 00 00 00 00 05 04 00 00 > > > > 0x3X is at 5, not at 3. > > > You still run with MPS 1.1. > It should be 3 or 19 after you reboot with MPS 1.4. > > Could you please try the following commands as root, but just before > rebooting. It'll kill the USB controller. > > #setpci -s 00:07.2 INTERRUPT_LINE=15 > #lspci -vx -s 00:07.2 > <<< 0x3C should be 15 > #setpci -s 00:07.2 INTERRUPT_LINE=19 > #lspci -vx -s 00:07.2 > <<< 0x3C is now either 19 or 3 > :setpci -s 00:07.2 INTERRUPT_LINE=15 :lspci -vx -s 00:07.2 00:07.2 USB Controller: VIA Technologies, Inc. UHCI USB (rev 16) (prog-if 00 [UHCI]) Subsystem: Unknown device 0925:1234 Flags: bus master, medium devsel, latency 32, IRQ 19 I/O ports at a000 [size=32] Capabilities: [80] Power Management version 2 30: 00 00 00 00 80 00 00 00 00 00 00 00 15 04 00 00 :setpci -s 00:07.2 INTERRUPT_LINE=19 :lspci -vx -s 00:07.2 00:07.2 USB Controller: VIA Technologies, Inc. UHCI USB (rev 16) (prog-if 00 [UHCI]) Subsystem: Unknown device 0925:1234 Flags: bus master, medium devsel, latency 32, IRQ 19 I/O ports at a000 [size=32] Capabilities: [80] Power Management version 2 30: 00 00 00 00 80 00 00 00 00 00 00 00 19 04 00 00 So that is correct. I'll attach all the information from the MPS 1.4 reboot, in which 00:07.2 happily points at 05, while everything else thinks it's at 19. 0: 000f - 0010 (reserved) BIOS-e820: 0010 - 1fff (usable) BIOS-e820: 1fff - 1fff3000 (ACPI NVS) BIOS-e820: 1fff3000 - 2000 (ACPI data) BIOS-e820: fec0 - fec01000 (reserved) BIOS-e820: fee0 - fee01000 (reserved) BIOS-e820: - 0001 (reserved) found SMP MP-table at 000f5770 hm, page 000f5000 reserved twice. hm, page 000f6000 reserved twice. hm, page 000f1000 reserved twice. hm, page 000f2000 reserved twice. On node 0 totalpages: 131056 zone(0): 4096 pages. zone(1): 126960 pages. zone(2): 0 pages. Intel MultiProcessor Specification v1.4 Virtual Wire compatibility mode. OEM ID: OEM0 Product ID: PROD APIC at: 0xFEE0 Processor #0 Pentium(tm) Pro APIC version 17 Processor #1 Pentium(tm) Pro APIC version 17 I/O APIC #2 Version 17 at 0xFEC0. Processors: 2 Kernel command line: auto BOOT_IMAGE=SuSE-2.4.5ac5 ro root=2101 BOOT_FILE=/boot/prod/vmlinuz-245ac5 video=matrox:vesa:0x11E,fv:80,sgram Total of 2 processors activated (2808.21 BogoMIPS). ENABLING IO-APIC IRQs ...changing IO-APIC physical APIC ID to 2 ... ok. init IO_APIC IRQs IO-APIC (apicid-pin) 2-0, 2-5, 2-10, 2-11, 2-15, 2-20, 2-21, 2-22, 2-23 not connected. ..TIMER: vector=49 pin1=2 pin2=0 number of MP IRQ sources: 22. number of IO-APIC #2 registers: 24. testing the IO APIC... IO APIC #2.. register #00: 0200 ...: physical APIC id: 02 register #01: 00178011 ... : max redirection entries: 0017 ... : IO APIC version: 0011 WARNING: unexpected IO-APIC, please mail to [EMAIL PROTECTED] register #02: ... : arbitration: 00 IRQ redirection table: NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect: 00 000 00 100 0 00000 01 003 03 000 0 01139 02 003 03 000 0 01131 03 003 03 000 0 01141 04 003 03 000 0 01149 05 000 00 100 0 00000 06 003 03 000 0 01151 07 003 03 000 0 01159 08 003 03 000 0 01161 09 003 03 000 0 01169 0a 000 00 100 0 00000 0b 000 00 100 0 00000 0c 003 03 000 0 01171 0d 003 03 000 0 01179 0e 003 03 000 0 01181 0f 000 00 100 0 00000 10 003 03 110 1 01189 11 003 03 110 1 01191 12 003 03 110 1 01199 13 003 03 110 1 011A1 14 000 00 100 0 00000 15 000 00 100 0 00000 16 000 00 100 0 00000 17 000 00 100 0 00000 IRQ to pin mappings: IRQ0 -> 0:2 IRQ1 -> 0:1 IRQ3 -> 0:3 IRQ4 -> 0:4 IRQ6 -> 0:6 IRQ7 -> 0:7 IRQ8 -> 0:8 IRQ9 -> 0:9 IRQ12 -> 0:12 IRQ13 -> 0:13 IRQ14 -> 0:14 IRQ16
Re: Abysmal RECV network performance
John William wrote: > > >Depends on what is driving it... An application I built can only push > >about > >80 Mbps bi-directional on PII 550Mhz machines. It is not the most > >efficient program in > >the world, but it isn't too bad either... > > > >I missed the rest of this thread, so maybe you already mentioned it, but > >what is the bottleneck? Is your CPU running at 100%? > > > >Greatly increasing the buffers both in the drivers and in the sockets > >does wonders for higher-speed connections, btw. > > > >Ben > > I don't know what the bottleneck is. What I'm seeing is ~60Mbps transmit > speed and anywhere from 1 to 12Mpbs receive speed on a couple 10/100 cards > using the 2.2.16, 2.2.19 and 2.4.3 kernels. > > I have tried increasing the size of the RX ring buffer and it did not seem > to make any difference. It appears that there is some sort of overrun or > other problem. There is a significant slowdown between the 2.2.x and 2.4.x > kernels. > > However, just tonight, while really hammering on the system, I started to > get some messages like "eth1: Oversized Ethernet frame spanned multiple > buffers, status 7fff8301!". Any ideas what could be causing that? Nope, I'd take it up with the driver developers. For what it's worth, the Intel Ether-Express Pro cards are the only ones I've found yet that really work right at high speeds. Intel's e100 driver seems to work really well for me, but the eepro driver also works well with most versions of the eepro cards I've used... I have had definate problems with the natsemi (locked up), tulip (won't autonegotiate multi-port cards correctly, or something), rtl8139 (would lock up, haven't tried recent drivers though) I used to assume that Linux had the best/fastest networking support around, but the reality is that I've had a really hard time finding hardware/drivers that works at high speeds (60Mbps+, bi-directional). -- Ben Greear <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> President of Candela Technologies Inc http://www.candelatech.com ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Patch for Promise PDC20267 FastTrack100 Controller
Hi! I've found that 2.4.5-ac kernels can't detect hdd's connected to FastTrack100 Promise controller, but Ultra100 works fine. Here is the patch, that solve this problem. Controllers tested - FastTrack100, Ultra100. Kernel - 2.4.5-ac4. -- Good luck, Konstantin linux-2.4.4-ac10-promise.patch
Re: Abysmal RECV network performance
>Depends on what is driving it... An application I built can only push >about >80 Mbps bi-directional on PII 550Mhz machines. It is not the most >efficient program in >the world, but it isn't too bad either... > >I missed the rest of this thread, so maybe you already mentioned it, but >what is the bottleneck? Is your CPU running at 100%? > >Greatly increasing the buffers both in the drivers and in the sockets >does wonders for higher-speed connections, btw. > >Ben I don't know what the bottleneck is. What I'm seeing is ~60Mbps transmit speed and anywhere from 1 to 12Mpbs receive speed on a couple 10/100 cards using the 2.2.16, 2.2.19 and 2.4.3 kernels. I have tried increasing the size of the RX ring buffer and it did not seem to make any difference. It appears that there is some sort of overrun or other problem. There is a significant slowdown between the 2.2.x and 2.4.x kernels. However, just tonight, while really hammering on the system, I started to get some messages like "eth1: Oversized Ethernet frame spanned multiple buffers, status 7fff8301!". Any ideas what could be causing that? - John _ Get your FREE download of MSN Explorer at http://explorer.msn.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[CHECKER] 2.4.5-ac4 use of freed pointers
Three use-after-free bugs:
-
[BUG]
/u2/engler/mc/oses/linux/2.4.5-ac4/net/rose/rose_dev.c:127:rose_rebuild_header:
ERROR:FREE:122:127: Use-after-free of 'skbn'! set by 'kfree_skb':122
skb_set_owner_w(skbn, skb->sk);
kfree_skb(skb);
if (!rose_route_frame(skbn, NULL)) {
Start --->
kfree_skb(skbn);
stats->tx_errors++;
}
stats->tx_packets++;
Error --->
stats->tx_bytes += skbn->len;
#endif
return 1;
}
-
[BUG] frees then uses the next pointer.
/u2/engler/mc/oses/linux/2.4.5-ac4/drivers/net/wan/lapbether.c:101:lapbeth_check_devices:
ERROR:FREE:113:101: Use-after-free of 'lapbeth'! set by 'kfree':113
save_flags(flags);
cli();
lapbeth_prev = NULL;
Error --->
for (lapbeth = lapbeth_devices; lapbeth != NULL; lapbeth = lapbeth->next) {
if (!dev_get(lapbeth->ethname)) {
if (lapbeth_prev)
lapbeth_prev->next = lapbeth->next;
else
lapbeth_devices = lapbeth->next;
if (>axdev == dev)
result = 1;
unregister_netdev(>axdev);
dev_put(lapbeth->ethdev);
Start --->
kfree(lapbeth);
}
else
lapbeth_prev = lapbeth;
-
[BUG] frees then uses the next pointer.
/u2/engler/mc/oses/linux/2.4.5-ac4/drivers/net/hamradio/bpqether.c:178:bpq_check_devices:
ERROR:FREE:193:178: Use-after-free of 'bpq'! set by 'kfree':193
save_flags(flags);
cli();
bpq_prev = NULL;
Error --->
for (bpq = bpq_devices; bpq != NULL; bpq = bpq->next) {
... DELETED 9 lines ...
/* We should be locked, call
* unregister_netdevice directly
*/
unregister_netdevice(>axdev);
Start --->
kfree(bpq);
}
else
bpq_prev = bpq;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[CHECKER] 2.4.5-ac4 security holes
Hi All,
Here's a few apparent security holes in 2.4.5-ac4. The biggest is in
fs/ioctl.c where it looks like a new option was added that seems to
write directly to the user pointer, essentially giving anyone complete
control over the machine.
4 | drivers/net/wan/cosa.c
2 | drivers/usb/bluetooth.c
1 | drivers/isdn/eicon/linchr.c
1 | drivers/sound/wavfront.c
1 | fs/ioctl.c
-
[BUG] looks really broken.
/u2/engler/mc/oses/linux/2.4.5-ac4/fs/ioctl.c:108:sys_ioctl: ERROR:PARAM:70:108: Deref
tainted var 'arg' (tainted from line 70)
case FIONCLEX:
set_close_on_exec(fd, 0);
break;
case FIONBIO:
Start --->
if ((error = get_user(on, (int *)arg)) != 0)
... DELETED 32 lines ...
case FIOQSIZE:
if (S_ISDIR(filp->f_dentry->d_inode->i_mode) ||
S_ISREG(filp->f_dentry->d_inode->i_mode) ||
S_ISLNK(filp->f_dentry->d_inode->i_mode))
Error --->
*(loff_t *)arg =
inode_get_bytes(filp->f_dentry->d_inode);
else
error = -ENOTTY;
break;
-
[BUG] sure seems like it. In general, all 4 dereferences seem pretty bad.
/u2/engler/mc/oses/linux/2.4.5-ac4/drivers/net/wan/cosa.c:1049:cosa_download:
ERROR:PARAM:1046:1049: Deref tainted var 'd' (tainted from line 1046)
return -EPERM;
}
if (get_user(addr, &(d->addr)) ||
__get_user(len, &(d->len)) ||
Start --->
__get_user(code, &(d->code)))
return -EFAULT;
Error --->
if (d->addr < 0 || d->addr > COSA_MAX_FIRMWARE_SIZE)
return -EINVAL;
if (d->len < 0 || d->len > COSA_MAX_FIRMWARE_SIZE)
return -EINVAL;
-
[BUG] why copy it in then use the inital thing?
/u2/engler/mc/oses/linux/2.4.5-ac4/drivers/net/wan/cosa.c:1057:cosa_download:
ERROR:PARAM:1046:1057: Deref tainted var 'd' (tainted from line 1046)
return -EPERM;
}
if (get_user(addr, &(d->addr)) ||
__get_user(len, &(d->len)) ||
Start --->
__get_user(code, &(d->code)))
return -EFAULT;
if (d->addr < 0 || d->addr > COSA_MAX_FIRMWARE_SIZE)
return -EINVAL;
if (d->len < 0 || d->len > COSA_MAX_FIRMWARE_SIZE)
return -EINVAL;
/* If something fails, force the user to reset the card */
cosa->firmware_status &= ~(COSA_FW_RESET|COSA_FW_DOWNLOAD);
Error --->
if ((i=download(cosa, d->code, len, addr)) < 0) {
printk(KERN_NOTICE "cosa%d: microcode download failed: %d\n",
cosa->num, i);
return -EIO;
-
[BUG] seems retty clear
/u2/engler/mc/oses/linux/2.4.5-ac4/drivers/sound/wavfront.c:2049:wavefront_oss_ioctl:
ERROR:PARAM:2072:2049: tainted var 'arg' (from line 2072) used as arg 0 to 'memcpy'
int err;
switch (cmd) {
case SNDCTL_SYNTH_INFO:
memcpy (&((char *) arg)[0], _info,
Error --->
sizeof (wavefront_info));
... DELETED 17 lines ...
return dev.freemem;
}
break;
case SNDCTL_SYNTH_CONTROL:
Start --->
copy_from_user (, arg, sizeof (wc));
if ((err = wavefront_synth_control (cmd, )) == 0) {
copy_to_user (arg, , sizeof (wc));
-
[BUG] fixed in ac5, I believe.
/u2/engler/mc/oses/linux/2.4.5-ac4/drivers/usb/bluetooth.c:438:bluetooth_write:
ERROR:PARAM:461:438: Deref tainted var 'buf' (tainted from line 461)
}
#ifdef DEBUG
printk (KERN_DEBUG __FILE__ ": " __FUNCTION__ " - length = %d, data = ",
count);
for (i = 0; i < count; ++i) {
Error --->
printk ("%.2x ", buf[i]);
... DELETED 17 lines ...
err (__FUNCTION__ "- out of memory.");
return -ENOMEM;
}
if (from_user)
Start --->
copy_from_user (new_buffer, buf+1, count-1);
else
memcpy (new_buffer, buf+1, count-1);
-
[BUG]
/u2/engler/mc/oses/linux/2.4.5-ac4/drivers/usb/bluetooth.c:431:bluetooth_write:
ERROR:PARAM:461:431: Deref tainted var 'buf' (tainted from line 461)
if (count == 0) {
dbg(__FUNCTION__ " - write request of 0
Re: [PATCH] support for Cobalt Networks (x86 only) systems (for realthis time)
Tim Hockin said once upon a time (Thu, 31 May 2001): > Aattached is a (large, but self contained) patch for Cobalt Networks suport > for x86 systems (RaQ3, RaQ4, Qube3, RaQXTR). Please let me know if there > is anything that would prevent this from general inclusion in the next > release. I can vouch for these patches stability wise. I've been running an earlier version of these patches (for 2.4.4) on a Qube 3 acting as a firewall for 3 weeks without any problems. Incidently, that Qube 3 is running Red Hat 7.1 and using reiserfs on all filesystems except for /boot. Dax - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Abysmal RECV network performance
John William wrote: > > >I've seen many reports like this where the NIC is invalidly in > >full-duplex more while the router is in half-duplex mode. > > [root@copper diag]# ./tulip-diag eth1 -m > tulip-diag.c:v2.08 5/15/2001 Donald Becker ([EMAIL PROTECTED]) > http://www.scyld.com/diag/index.html > Index #1: Found a Lite-On 82c168 PNIC adapter at 0xfe00. > Port selection is MII, full-duplex. > Transmit started, Receive started, full-duplex. > The Rx process state is 'Waiting for packets'. > The Tx process state is 'Idle'. > The transmit threshold is 512. > MII PHY found at address 1, status 0x782d. > MII PHY #1 transceiver registers: >1000 782d 7810 01e1 41e1 0001 > > 4000 38c8 0010 0002 >0001 . > [root@copper diag]# ./mii-diag eth1 > Basic registers of MII PHY #1: 1000 782d 7810 01e1 41e1 0001 . > The autonegotiated capability is 01e0. > The autonegotiated media type is 100baseTx-FD. > Basic mode control register 0x1000: Auto-negotiation enabled. > You have link beat, and everything is working OK. > Your link partner advertised 41e1: 100baseTx-FD 100baseTx 10baseT-FD > 10baseT. >End of basic transceiver informaion. > > On the NetGear switch, I have indicator lights for 100baseT-FD on both > connections used for testing. So it appears to me that everything is working > correctly (hardware). > > I keep coming back to a problem with the kernel, or that somehow I have two > cards (FA310 and 3CSOHO) defective in almost exactly the same way, but only > on receive. If it were a hardware problem, why would I only get poor > performance in one direction and not both? > > Does anyone have network performance numbers for a comparable machine (P-90 > class)? I'm thinking I should expect 50-70Mbps on a PCI 10/100 ethernet card > from a P-90 class machine, right? Depends on what is driving it... An application I built can only push about 80 Mbps bi-directional on PII 550Mhz machines. It is not the most efficient program in the world, but it isn't too bad either... I missed the rest of this thread, so maybe you already mentioned it, but what is the bottleneck? Is your CPU running at 100%? Greatly increasing the buffers both in the drivers and in the sockets does wonders for higher-speed connections, btw. Ben -- Ben Greear <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> President of Candela Technologies Inc http://www.candelatech.com ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [lkml]Re: interrupt problem with MPS 1.4 / not with MPS 1.1 ?
Manfred Spraul wrote: > > > > > I know that with MPS 1.4, the USB controller finds itself at an > > unshared interrupt 19. I can't reboot at the moment to check. > > > lspci -vxxx -s 00:07.0 > > the APIC sits in the southbridge. > the low 2 bits of offset 0x58 must be set [route USB IRQ to APIC], and > > lspci -vx -s 00:07.2 > > offset 0x3C must be set to 3 [19 & 15] > > There was some discussion about the same problem with the sound part of > the southbridge. If an IO-APIC is present, 2.4.5 automatically routes all Via IRQs to external APIC. See quirk_via_ioapic in drivers/pci/quirks.c. I have received reports that MPS1.1 works on SMP Via boards, while MPS1.4 kills it. -- Jeff Garzik | Disbelief, that's why you fail. Building 1024| MandrakeSoft | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
should reiserfs root be ro?
Should a box that has its root filesystem on a reiser fs mount this root readonly? i.e. should 'read-only' be in lilo.conf? -- John Lenton ([EMAIL PROTECTED]) -- Random fortune: It seems like the less a statesman amounts to, the more he loves the flag. PGP signature
Re: How to know HZ from userspace?
Followup to: <[EMAIL PROTECTED]> By author:Ralf Baechle <[EMAIL PROTECTED]> In newsgroup: linux.dev.kernel > > On Wed, May 30, 2001 at 05:07:22PM -0700, H. Peter Anvin wrote: > > > Yes, but that's because the interfaces are broken. The decision has > > been that these values should be exported using the default HZ for the > > architecture, and that it is the kernel's responsibility to scale them > > when HZ != USER_HZ. I don't know if any work has been done in this > > area. > > We have such patches in the MIPS tree but I never dared to send them to > Linus ... > Please do. -=hpa -- <[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PID of init != 1 when initrd with pivot_root
Followup to: <[EMAIL PROTECTED]> By author:Ivan <[EMAIL PROTECTED]> In newsgroup: linux.dev.kernel > > Well, I upgraded and found pivot_root and the problem is that how do I make init > run with PID 1. My linuxrc gets PID 7. > > 1 ?00:03:05 swapper > 2 ?00:00:00 keventd > 3 ?00:00:00 kswapd > 4 ?00:00:00 kreclaimd > 5 ?00:00:00 bdflush > 6 ?00:00:00 kupdated > 7 ?00:00:00 linuxrc > > init doesn't like running with any other PID than 1. I could probably revert to > the not so old way of doing things and exit linuxrc and let the kernel change > root. But then I wouldn't be able to mount root over samba :-(. ( not that I > have any samba shares :-) > This is this way for backwards bug compatibility. Use the following command line options to make it behave properly: ram=/dev/ram0 init=/linuxrc -hpa -- <[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] support for Cobalt Networks (x86 only) systems (for real this time)
> Aattached is a (large, but self contained) patch for Cobalt Networks suport
> for x86 systems (RaQ3, RaQ4, Qube3, RaQXTR). Please let me know if there
> is anything that would prevent this from general inclusion in the next
> release.
Looks interesting. Seemingly literate use of spinlocks.
Off-hand I see old style initialization. Is it right for new driver?
i2c framework is not used, I wonder why. Someone thought that
it was too heavy perhaps? If so, I disagree.
Also, I am curious
if any alignment with lm-sensors is possible, for the sake of
common userland tools? If we managed that, PSARC would eat their
hearts out - they tried to do it since E-250 shipped.
lcd_read bounces reads with -EINVAL when another read is in
progress. Gross.
Nitpicking:
1.:
p = head;
while (p) {
p = p->next;
}
It is what for(;;) does.
2. Spaces and tabs are mixed in funny ways, makes to cute effects
when quoting diffs.
-- Pete
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: how to crash 2.4.4 w/SBLive
On Thu, May 31, 2001 at 12:01:05PM +0200, [EMAIL PROTECTED] wrote: Content-Description: emu10k1 patch > Index: audio.c > === > RCS file: /usr/local/cvsroot/emu10k1/audio.c,v > retrieving revision 1.166 > diff -u -r1.166 audio.c > --- audio.c 2001/04/22 15:44:25 1.166 > +++ audio.c 2001/05/31 08:47:25 > @@ -1231,6 +1231,7 @@ > woinst->buffer.ossfragshift = 0; > woinst->buffer.numfrags = 0; > woinst->device = (card->audio_dev1 == minor); > + woinst->timer.state = TIMER_STATE_UNINSTALLED; > > init_waitqueue_head(>wait_queue); the closest I can find (in 2.4.5) is woinst->buffer.fragment_size = 0; woinst->buffer.ossfragshift = 0; woinst->buffer.numfrags = 0; woinst->device = (card->audio1_num == minor); init_waitqueue_head(>wait_queue); at lines --1116... -- John Lenton ([EMAIL PROTECTED]) -- Random fortune: New York... when civilization falls apart, remember, we were way ahead of you. - David Letterman PGP signature
Re: Abysmal RECV network performance
>I've seen many reports like this where the NIC is invalidly in
>full-duplex more while the router is in half-duplex mode.
[root@copper diag]# ./tulip-diag eth1 -m
tulip-diag.c:v2.08 5/15/2001 Donald Becker ([EMAIL PROTECTED])
http://www.scyld.com/diag/index.html
Index #1: Found a Lite-On 82c168 PNIC adapter at 0xfe00.
Port selection is MII, full-duplex.
Transmit started, Receive started, full-duplex.
The Rx process state is 'Waiting for packets'.
The Tx process state is 'Idle'.
The transmit threshold is 512.
MII PHY found at address 1, status 0x782d.
MII PHY #1 transceiver registers:
1000 782d 7810 01e1 41e1 0001
4000 38c8 0010 0002
0001 .
[root@copper diag]# ./mii-diag eth1
Basic registers of MII PHY #1: 1000 782d 7810 01e1 41e1 0001 .
The autonegotiated capability is 01e0.
The autonegotiated media type is 100baseTx-FD.
Basic mode control register 0x1000: Auto-negotiation enabled.
You have link beat, and everything is working OK.
Your link partner advertised 41e1: 100baseTx-FD 100baseTx 10baseT-FD
10baseT.
End of basic transceiver informaion.
On the NetGear switch, I have indicator lights for 100baseT-FD on both
connections used for testing. So it appears to me that everything is working
correctly (hardware).
I keep coming back to a problem with the kernel, or that somehow I have two
cards (FA310 and 3CSOHO) defective in almost exactly the same way, but only
on receive. If it were a hardware problem, why would I only get poor
performance in one direction and not both?
Does anyone have network performance numbers for a comparable machine (P-90
class)? I'm thinking I should expect 50-70Mbps on a PCI 10/100 ethernet card
from a P-90 class machine, right?
- John
_
Get your FREE download of MSN Explorer at http://explorer.msn.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: missing sysrq
> D. Stimits wrote: > > > Bernd Eckenfels wrote: > > > > > In article <[EMAIL PROTECTED]> you wrote: > > > However, if I go to /proc/sys/kernel/sysrq does not exist. > > > > It is a compile time option, so the person who compiled your kernel > > left it out. > > I compiled it, and the sysrq is definitely in the config. No doubt at > all. I also use make mrproper and config again before dep and actual > compile. Maybe it is just a quirk/oddball. > > D. Stimits, [EMAIL PROTECTED] Have you tried "echo 1 > /proc/sys/kernel/sysrq"? You need both, compiled in and activation. Regards, Dieter -- Dieter Nützel Graduate Student, Computer Science email: [EMAIL PROTECTED] @home: [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [reiserfs-list] Re: Why side-effects on open(2) are evil. (was Re: [RFD w/info-PATCH]device arguments from lookup)
Daniel Phillips wrote: > Graciously accepted. Coming up with something sensible in a mere 6 > months would be a minor miracle. ;-) > > - what happens if the user forgets to close the transaction? then the user has branched into his own version, or at least that would be my take on it. Another possible method is to expire transactions by persons who lack permission to keep them open indefinitely. I suppose one could expire them to abort, or expire them to commit, both being valid under some circumstances. > >I plan to set a checkpoint there (because the transaction got >too big) and log the fact that it's open. > > - issues of lock/transaction duration > >Once again relying on checkpoints, when the transaction gets >uncomfortably big for cache, set a checkpoint. I haven't thought >about locks > > - transaction batching > >1) Explicit transaction batch close 2) Cache gets past a certain >fullness. In both cases, no new transactions are allowed to start >and as soon as all current ones are closed we close the batch.re6; > > - of levels of isolation > - concurrent transactions modifying global fs metadata >and some but not all of those concurrent transactions receiving a >rollback > >First I was going to write 'huh?' here, then I realized you're >talking about real database ops, not just filesystem ops. I had >in mind something more modest: transactions are 'mv', 'read/write' >(if the 'atomic read/write' is set), other filesystem operations I've >forgotten, and anything the user puts between open_xact and >close_xact. You are raising the ante a little ;-) > >In my case (Tux2) I could do an efficient rollback to the beginning > of the batch (phase), then I would have had to have kept an >in-memory log of the transactions for selective replay. With a >journal log you can obviously do the same thing, but perhaps more >efficiently if your journal design supports undo/redo. > >The above is a pure flight of fancy, we won't be seeing anything >so fancy as an API across filesystems. It is just a matter of time, and we will. I think that the major release AFTER 2.6 will see it. First we have to get a prototype done in time for 2.6 > > - permissions relating to keeping transactions open. >We can see this one in the light of a simple filesystem >transaction: what happens if we are in the middle of a mv and >someone changes the permissions? Go with the starting or >ending permissions? > > Well, the database side of this is really interesting, but to get > something generic across filesystems, the scope pretty well has to be > limited to journal-type transactions, don't you think? don't know what a journal-type transaction is and how it differs from a database transaction. > > -- > Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] save source address on accept()
Tim Hockin writes: > attached is a (small) patch which saves the src address on tcp_accept(). > Please let me know if there are any problems taking this for general > inclusion. And what would this even be used for? I see no need for it. Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: include/asm-sparc/ptrace.h is broken
Felix von Leitner writes:
> on line 76, it includes , which does not exist.
>
> This is critical because this include file does not work when used from
> a libc. ptrace.h is from 1997 on my 2.4.5 kernel, so this is not
> something that broke recently.
>
> My suggestion is to remove the offending line altogether or at least
> protect it with #ifdef __KERNEL__.
Just like other headers in the kernel (such as linux/autoconfig.h)
they do not exist until the kernel is configured and built.
include asm-sparc{,64}/asm_offsets.h is built at kernel build time.
Later,
David S. Miller
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] support for Cobalt Networks (x86 only) systems (for real this time)
apparently, LKML silently (!) bounces messages > a certain size. So I'll
try smaller patches. This is part 2/2 of the general Cobalt support.
Alan,
Aattached is a (large, but self contained) patch for Cobalt Networks suport
for x86 systems (RaQ3, RaQ4, Qube3, RaQXTR). Please let me know if there
is anything that would prevent this from general inclusion in the next
release.
(patch against 2.4.5)
Thanks
Tim
--
Tim Hockin
Systems Software Engineer
Sun Microsystems, Cobalt Server Appliances
[EMAIL PROTECTED]
diff -ruN dist-2.4.5/drivers/cobalt/README cobalt-2.4.5/drivers/cobalt/README
--- dist-2.4.5/drivers/cobalt/READMEWed Dec 31 16:00:00 1969
+++ cobalt-2.4.5/drivers/cobalt/README Thu May 31 14:32:15 2001
@@ -0,0 +1,19 @@
+Notes on Cobalt's drivers:
+
+You will notice in several places constructs such as this:
+
+ if (cobt_is_3k()) {
+ foo();
+ } else if (cobt_is_5k()) {
+ bar();
+ }
+
+The goal here is to only compile in code that is needed, but to allow one to
+define support for both 3k and 5k (and more?) style systems. The systype
+check macros are very simple and clean. They check whether config-time
+support for the generation has been enabled, and (if so) whether systype
+detected the specified generation. This leaves the code free from #ifdef
+cruft, but lets the compiler throw out unsupported generation-specific code
+with if (0) detection.
+
+--
diff -ruN dist-2.4.5/drivers/cobalt/ruler.c cobalt-2.4.5/drivers/cobalt/ruler.c
--- dist-2.4.5/drivers/cobalt/ruler.c Wed Dec 31 16:00:00 1969
+++ cobalt-2.4.5/drivers/cobalt/ruler.c Thu May 31 14:32:15 2001
@@ -0,0 +1,393 @@
+/*
+ * cobalt ruler driver
+ * Copyright (c) 2000, Cobalt Networks, Inc.
+ * $Id: ruler.c,v 1.10 2001/05/30 07:19:48 thockin Exp $
+ *
+ * author: [EMAIL PROTECTED], [EMAIL PROTECTED]
+ *
+ * This should be SMP safe. There are two critical pieces of data, and thsu
+ * two locks. The ruler_lock protects the arrays of channels(hwifs) and
+ * busproc function pointers. These are only ever written in the
+ * register/unregister functions but read in several other places. A
+ * read/write lock is appropriate. The second lock is the lock on the sled
+ * led state and the I2C_DEV_RULER. It gets called from timer context, so
+ * irqsave it. The global switches and sled_leds are atomic_t. --TPH
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define RULER_TIMEOUT (HZ >> 1) /* .5s */
+#define MAX_COBT_DRIVES4
+#define LED_SLED0 (1 << 3)
+#define LED_SLED1 (1 << 2)
+#define LED_SLED2 (1 << 1)
+#define LED_SLED3 (1 << 0)
+
+/* all of this is for gen V */
+static struct timer_list cobalt_ruler_timer;
+static rwlock_t ruler_lock = RW_LOCK_UNLOCKED;
+static spinlock_t rled_lock = SPIN_LOCK_UNLOCKED;
+static ide_hwif_t *channels[MAX_COBT_DRIVES];
+static ide_busproc_t *busprocs[MAX_COBT_DRIVES];
+/* NOTE: switches is a bitmask of DETACHED sleds */
+static atomic_t switches = ATOMIC_INIT(0);
+static atomic_t sled_leds = ATOMIC_INIT(0);
+static int sled_led_map[] = {LED_SLED0, LED_SLED1, LED_SLED2, LED_SLED3};
+static int ruler_detect;
+
+static inline u8
+read_switches(void)
+{
+ u8 state = 0;
+ if (cobt_is_5k()) {
+ int tries = 3;
+
+ /* i2c can be busy, and this can read wrong - try a few times */
+ while (tries--) {
+ state = cobalt_i2c_read_byte(COBALT_I2C_DEV_DRV_SWITCH,
+ 0);
+ if ((state & 0xf0) != 0xf0) {
+ break;
+ }
+ }
+ }
+
+ return state;
+}
+
+/*
+ * deal with sled leds: LED on means OK to remove
+ * NOTE: all the reset lines are kept high.
+ * NOTE: the reset lines are in the reverse order of the switches.
+ */
+static void
+set_sled_leds(u8 leds)
+{
+ if (cobt_is_5k()) {
+ unsigned long flags;
+
+ spin_lock_irqsave(_lock, flags);
+
+ atomic_set(_leds, leds);
+ leds |= 0xf0;
+ cobalt_i2c_write_byte(COBALT_I2C_DEV_RULER, 0, leds);
+
+ spin_unlock_irqrestore(_lock, flags);
+ }
+}
+
+static inline u8
+get_sled_leds(void)
+{
+ return atomic_read(_leds);
+}
+
+/* this must be called with the ruler_lock held for read */
+static int
+do_busproc(int idx, ide_hwif_t *hwif, int arg)
+{
+ if (cobt_is_5k()) {
+ /* sed sled LEDs */
+ switch (arg) {
+ case BUSSTATE_ON:
+ set_sled_leds(get_sled_leds() &
+ ~sled_led_map[idx]);
+
[PATCH] support for Cobalt Networks (x86 only) systems (for real this time)
apparently, LKML silently (!) bounces messages > a certain size. So I'll
try smaller patches. This is part 1/2 of the general Cobalt support.
Alan,
Aattached is a (large, but self contained) patch for Cobalt Networks suport
for x86 systems (RaQ3, RaQ4, Qube3, RaQXTR). Please let me know if there
is anything that would prevent this from general inclusion in the next
release.
(patch against 2.4.5)
Thanks
Tim
--
Tim Hockin
Systems Software Engineer
Sun Microsystems, Cobalt Server Appliances
[EMAIL PROTECTED]
diff -ruN dist-2.4.5/drivers/cobalt/acpi.c cobalt-2.4.5/drivers/cobalt/acpi.c
--- dist-2.4.5/drivers/cobalt/acpi.cWed Dec 31 16:00:00 1969
+++ cobalt-2.4.5/drivers/cobalt/acpi.c Thu May 31 14:32:15 2001
@@ -0,0 +1,218 @@
+/*
+ * cobalt acpi driver
+ * Copyright (c) 2000, Cobalt Networks, Inc.
+ * Copyright (c) 2001, Sun Microsystems, Inc.
+ * $Id: acpi.c,v 1.10 2001/05/30 07:19:47 thockin Exp $
+ *
+ * author: [EMAIL PROTECTED], [EMAIL PROTECTED]
+ *
+ * this driver just sets stuff up for ACPI interrupts
+ *
+ * if acpi support really existed in the kernel, we would read
+ * data from the ACPI tables. however, it doesn't. as a result,
+ * we use some hardcoded values.
+ *
+ * This should be SMP safe. The only data that needs protection is the acpi
+ * handler list. It gets scanned at timer-interrupts, must use
+ * irqsave/restore locks. Read/write locks would be useful if there were any
+ * other times that the list was read but never written. --TPH
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define POWER_BUTTON_SHUTDOWN 0
+
+#define ACPI_IRQ 10 /* XXX: hardcoded interrupt */
+#define ACPI_NAME "sci"
+#define ACPI_MAGIC 0xc0b7ac21
+
+#define SUPERIO_EVENT 0xff
+#define OSB4_EVENT 0x40
+#define OSB4_INDEX_PORT0x0cd6
+#define OSB4_DATA_PORT 0x0cd7
+
+/* for registering ACPI handlers */
+struct acpi_handler {
+ void (*function)(int irq, void *dev_id, struct pt_regs *regs);
+ struct acpi_handler *next;
+ struct acpi_handler *prev;
+};
+struct acpi_handler *acpi_handler_list;
+
+static spinlock_t acpi_lock = SPIN_LOCK_UNLOCKED;
+/* these two are for gen V */
+static u16 osb4_port;
+static u16 superio_port;
+
+static u16
+get_reg(u16 index, u16 data, u8 port)
+{
+ if (cobt_is_5k()) {
+ u16 reg;
+
+ outb(port, index);
+ reg = inb(data);
+ outb(port + 1, index);
+ reg |= inb(data) << 8;
+ return reg;
+ }
+
+ return 0;
+}
+
+static void
+acpi_interrupt(int irq, void *dev_id, struct pt_regs *regs)
+{
+ unsigned long flags, events;
+ struct acpi_handler *p;
+
+ spin_lock_irqsave(_lock, flags);
+
+ if (cobt_is_5k()) {
+ /* save the superio events */
+ events = inb(superio_port) | (inb(superio_port + 1) << 8);
+
+ /* clear SCI interrupt generation */
+ outb(OSB4_EVENT, osb4_port);
+ outb(SUPERIO_EVENT, superio_port);
+ outb(SUPERIO_EVENT, superio_port + 1);
+ }
+
+ /* call the ACPI handlers */
+ p = acpi_handler_list;
+ while (p) {
+ p->function(irq, dev_id, regs);
+ p = p->next;
+ }
+
+ spin_unlock_irqrestore(_lock, flags);
+}
+
+int
+cobalt_acpi_register_handler(void (*function)(int, void *, struct pt_regs *))
+{
+ struct acpi_handler *newh;
+ unsigned long flags;
+
+ newh = kmalloc(sizeof(*newh), GFP_ATOMIC);
+ if (!newh) {
+ EPRINTK("can't allocate memory for handler %p\n", function);
+ return -1;
+ }
+
+ spin_lock_irqsave(_lock, flags);
+
+ /* head insert */
+ newh->function = function;
+ newh->next = acpi_handler_list;
+ newh->prev = NULL;
+ if (acpi_handler_list) {
+ acpi_handler_list->prev = newh;
+ }
+ acpi_handler_list = newh;
+
+ spin_unlock_irqrestore(_lock, flags);
+
+ return 0;
+}
+
+int
+cobalt_acpi_unregister_handler(void (*function)(int, void *, struct pt_regs *))
+{
+ struct acpi_handler *p;
+ unsigned long flags;
+ int r = -1;
+
+ spin_lock_irqsave(_lock, flags);
+
+ p = acpi_handler_list;
+ while (p) {
+ if (p->function == function) {
+ if (p->prev) {
+ p->prev->next = p->next;
+ }
+ if (p->next) {
+ p->next->prev = p->prev;
+ }
+ r = 0;
+ break;
+ }
+ p = p->next;
+ }
+
+ spin_unlock_irqrestore(_lock, flags);
+
+ return r;
+}
+
+int __init
+cobalt_acpi_init(void)
+{
+
Linux Ethernet
Hi, Team I am useing a dynamic address to access the cable modem. But I cann't establishe the eth0 interface. It looks I didn't receive a address. The ethernet card is connected to a cable modem. The second question is I recompiled the kernal which included Crystal sound card. And it passed when system boot. But I cann't get any voice service. Would anybody kindly help me? Sincerely Yours, Yunqu Liu [EMAIL PROTECTED] _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] almost forgot this one
Add a rwproc entry to the ide structure, for recalling what happened last time! Please let me knwo if there are any problems with this patch (some of the patches I sent earlier depend on this). Tim -- Tim Hockin Systems Software Engineer Sun Microsystems, Cobalt Server Appliances [EMAIL PROTECTED] diff -ruN dist-2.4.5/include/linux/ide.h ../cobalt-2.4.5/include/linux/ide.h --- dist-2.4.5/include/linux/ide.h Thu May 31 18:22:46 2001 +++ ../cobalt-2.4.5/include/linux/ide.h Thu May 31 14:33:16 2001 @@ -284,6 +284,7 @@ unsigned long service_time; /* service time of last request */ unsigned long timeout; /* max time to wait for irq */ special_t special;/* special action flags */ + void *rwproc_cache; /* last rwproc update */ byte keep_settings; /* restore settings after drive reset */ byte using_dma; /* disk is using dma for read/write */ byte waiting_for_dma; /* dma currently in progress */
PID of init != 1 when initrd with pivot_root
Well, I upgraded and found pivot_root and the problem is that how do I make init run with PID 1. My linuxrc gets PID 7. 1 ?00:03:05 swapper 2 ?00:00:00 keventd 3 ?00:00:00 kswapd 4 ?00:00:00 kreclaimd 5 ?00:00:00 bdflush 6 ?00:00:00 kupdated 7 ?00:00:00 linuxrc init doesn't like running with any other PID than 1. I could probably revert to the not so old way of doing things and exit linuxrc and let the kernel change root. But then I wouldn't be able to mount root over samba :-(. ( not that I have any samba shares :-) Ivan Vadovic - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: How to know HZ from userspace?
On Wed, May 30, 2001 at 05:07:22PM -0700, H. Peter Anvin wrote: > Yes, but that's because the interfaces are broken. The decision has > been that these values should be exported using the default HZ for the > architecture, and that it is the kernel's responsibility to scale them > when HZ != USER_HZ. I don't know if any work has been done in this > area. We have such patches in the MIPS tree but I never dared to send them to Linus ... Ralf - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] support for Cobalt Networks (x86 only) systems
> Aattached is a (large, but self contained) patch for Cobalt Networks suport Is not? ;) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] support for Cobalt Networks (x86 only) systems
Alan, Aattached is a (large, but self contained) patch for Cobalt Networks suport for x86 systems (RaQ3, RaQ4, Qube3, RaQXTR). Please let me know if there is anything that would prevent this from general inclusion in the next release. (patch against 2.4.5) Thanks Tim -- Tim Hockin Systems Software Engineer Sun Microsystems, Cobalt Server Appliances [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] HPT370 misc (for real this time)
Andre,
Attached is a patch for hpt366.c for the following:
better support for multiple controllers
better /proc output
66 MHz PCI timings
implement the HDIO_GET/SET_BUSSTATE ioctls (see previous patch)
This patch does rely on the PCI busspeed patch (sent to lkml earlier).
Please let me know if you have any problems with this for general
inclusion.
Tim
--
Tim Hockin
Systems Software Engineer
Sun Microsystems, Cobalt Server Appliances
[EMAIL PROTECTED]
diff -ruN dist-2.4.5/drivers/ide/hpt366.c cobalt-2.4.5/drivers/ide/hpt366.c
--- dist-2.4.5/drivers/ide/hpt366.c Sat May 19 17:43:06 2001
+++ cobalt-2.4.5/drivers/ide/hpt366.c Thu May 31 14:32:15 2001
@@ -11,6 +11,17 @@
*
* Note that final HPT370 support was done by force extraction of GPL.
*
+ * add function for getting/setting power status of drive
+ * Adrian Sun <[EMAIL PROTECTED]>
+ *
+ * add drive timings for 66MHz PCI bus,
+ * fix ATA Cable signal detection, fix incorrect /proc info
+ * add /proc display for per-drive PIO/DMA/UDMA mode and
+ * per-channel ATA-33/66 Cable detect.
+ * Duncan Laurie <[EMAIL PROTECTED]>
+ *
+ * fixup /proc output for multiple controllers
+ * Tim Hockin <[EMAIL PROTECTED]>
*/
#include
@@ -28,6 +39,7 @@
#include
#include
+#include
#include
#include
@@ -170,62 +182,126 @@
{ 0, 0x06514e57, 0x06514e57 }
};
+struct chipset_bus_clock_list_entry sixty_six_base_hpt370[] = {
+ { XFER_UDMA_5,0x14846231, 0x14846231 },
+ { XFER_UDMA_4,0x14886231, 0x14886231 },
+ { XFER_UDMA_3,0x148c6231, 0x148c6231 },
+ { XFER_UDMA_2,0x148c6231, 0x148c6231 },
+ { XFER_UDMA_1,0x14906231, 0x14906231 },
+ { XFER_UDMA_0,0x14986231, 0x14986231 },
+
+ { XFER_MW_DMA_2, 0x26514e21, 0x26514e21 },
+ { XFER_MW_DMA_1, 0x26514e33, 0x26514e33 },
+ { XFER_MW_DMA_0, 0x26514e97, 0x26514e97 },
+
+ { XFER_PIO_4, 0x06514e21, 0x06514e21 },
+ { XFER_PIO_3, 0x06514e22, 0x06514e22 },
+ { XFER_PIO_2, 0x06514e33, 0x06514e33 },
+ { XFER_PIO_1, 0x06914e43, 0x06914e43 },
+ { XFER_PIO_0, 0x06914e57, 0x06914e57 },
+ { 0, 0x06514e57, 0x06514e57 }
+};
+
#define HPT366_DEBUG_DRIVE_INFO0
#define HPT370_ALLOW_ATA100_5 1
#define HPT366_ALLOW_ATA66_4 1
#define HPT366_ALLOW_ATA66_3 1
+#define HPT366_MAX_DEVS8
+
+static struct pci_dev *hpt_devs[HPT366_MAX_DEVS];
+static int n_hpt_devs;
+
+static unsigned int pci_rev_check_hpt3xx(struct pci_dev *dev);
+static unsigned int pci_rev2_check_hpt3xx(struct pci_dev *dev);
+byte hpt366_proc = 0;
+byte hpt363_shared_irq;
+byte hpt363_shared_pin;
+extern char *ide_xfer_verbose (byte xfer_rate);
#if defined(DISPLAY_HPT366_TIMINGS) && defined(CONFIG_PROC_FS)
static int hpt366_get_info(char *, char **, off_t, int);
extern int (*hpt366_display_info)(char *, char **, off_t, int); /* ide-proc.c */
extern char *ide_media_verbose(ide_drive_t *);
-static struct pci_dev *bmide_dev;
-static struct pci_dev *bmide2_dev;
static int hpt366_get_info (char *buffer, char **addr, off_t offset, int count)
{
- char *p = buffer;
- u32 bibma = bmide_dev->resource[4].start;
- u32 bibma2 = bmide2_dev->resource[4].start;
- char *chipset_names[] = {"HPT366", "HPT366", "HPT368", "HPT370", "HPT370A"};
- u8 c0 = 0, c1 = 0;
- u32 class_rev;
-
- pci_read_config_dword(bmide_dev, PCI_CLASS_REVISION, _rev);
- class_rev &= 0xff;
-
-/*
- * at that point bibma+0x2 et bibma+0xa are byte registers
- * to investigate:
- */
- c0 = inb_p((unsigned short)bibma + 0x02);
- if (bmide2_dev)
- c1 = inb_p((unsigned short)bibma2 + 0x02);
-
- p += sprintf(p, "\n%s Chipset.\n",
chipset_names[class_rev]);
- p += sprintf(p, "--- Primary Channel Secondary
Channel -\n");
- p += sprintf(p, "%sabled %sabled\n",
- (c0&0x80) ? "dis" : " en",
- (c1&0x80) ? "dis" : " en");
- p += sprintf(p, "--- drive0 - drive1 drive0
-- drive1 --\n");
- p += sprintf(p, "DMA enabled:%s %s %s
%s\n",
- (c0&0x20) ? "yes" : "no ", (c0&0x40) ? "yes" : "no ",
- (c1&0x20) ? "yes" : "no ", (c1&0x40) ? "yes" : "no " );
-
- p += sprintf(p, "UDMA\n");
- p += sprintf(p, "DMA\n");
- p += sprintf(p, "PIO\n");
[PATCH] HPT370 misc
Andre, Attached is a patch for hpt366.c for the following: better support for multiple controllers better /proc output 66 MHz PCI timings implement the HDIO_GET/SET_BUSSTATE ioctls (see previous patch) This patch does rely on the PCI busspeed patch (sent to lkml earlier). Please let me know if you have any problems with this for general inclusion. Tim -- Tim Hockin Systems Software Engineer Sun Microsystems, Cobalt Server Appliances [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[Fwd: Plain 2.4.5 VM... (and 2.4.5-ac3)]
Here is a message from Steve Kieu that he couldn't get through... -- Einstein did not prove that everything is relative. Einstein explained how the speed of light could be constant. Benjamin Redelings I <>< http://www.bol.ucla.edu/~bredelin/ Just add my experience here... I use up to 2.4.4 and it is fine ; swap usage increase much but only in 2.4.5-acx IMHO it is because Alan did some changes? test with staroffice 5.1 in 35Mb RAM 32M swap 100Mhz just start staroffice and check, then exit check kernel usage usage when exit time (sec) 2.4.4-pre4 2.5M2.5M 48 2.4.4 2.0M2.0M 48 2.4.5 3.5M3.5M 49 2.4.5-ac1 7.9M7.9M 49 In 2.4.4 and 2.4.4-pre4 I noticed the kernel DID free swap when it needs. For example when I ran netscape for a while typing email in a web mail form (that way netscape will make memory leak) swap usage sometimes 17M. Quit netscape it reduced to about 12M; of course leave a lot free memory). Start netscape again SWAP REDUCED TO about 2M , just a bit bigger at the fisrt time I start netscape. Steve --- Benjamin Redelings I <[EMAIL PROTECTED]> wrote: > Vincent Stemen wrote: > > The problem is, that's not true. These problems > are not slipping > > through because of lack of testers. > Just to add some sanity to this thread, I have been > using the 2.4.x > kernels ever since they came out, on my personal > workstation and on some > workstations that I administrate for fellow students > in my department > here at UCLA. They have basically worked fine for > me. They are not > perfect, but many of the 2.4.x releases have been a > big improvement over > the 2.2.x releases. For one, 2.4.x actually can > tell which pages are > not used, and swap out unused daemons, which helps a > lot on a 64Mb box :) > > -BenR > -- > Einstein did not prove that everything is relative. > Einstein explained how the speed of light could be > constant. > Benjamin Redelings I <>< > http://www.bol.ucla.edu/~bredelin/ > > - > To unsubscribe from this list: send the line > "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at > http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ = S.KIEU _ http://messenger.yahoo.com.au - Yahoo! Messenger - Voice chat, mail alerts, stock quotes and favourite news and lots more!
Re: [PATCH] new PCI ids
On Thu, May 31, 2001 at 06:17:06PM -0700, Tim Hockin wrote: > Attached is a patch for cleaning up some PCI ids and adding a few that were > missing. Please let me know of any problems with this. > > (diff against 2.4.5) > > Tim > > -- > Tim Hockin > Systems Software Engineer > Sun Microsystems, Cobalt Server Appliances > [EMAIL PROTECTED] > diff -ruN dist-2.4.5/drivers/pci/pci.ids cobalt-2.4.5/drivers/pci/pci.ids > --- dist-2.4.5/drivers/pci/pci.idsSat May 19 17:49:14 2001 > +++ cobalt-2.4.5/drivers/pci/pci.ids Thu May 31 14:32:33 2001 > @@ -4,7 +4,7 @@ > #Maintained by Martin Mares <[EMAIL PROTECTED]> > #If you have any new entries, send them to the maintainer. > # > -#$Id: pci.ids,v 1.62 2000/06/28 10:56:36 mj Exp $ > +#$Id: pci.ids,v 1.3 2001/04/04 20:40:25 thockin Exp $ Shouldn't that be 1.63?! /David Weinehall _ _ // David Weinehall <[EMAIL PROTECTED]> /> Northern lights wander \\ // Project MCA Linux hacker// Dance across the winter sky // \> http://www.acc.umu.se/~tao/http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] save source address on accept()
All, attached is a (small) patch which saves the src address on tcp_accept(). Please let me know if there are any problems taking this for general inclusion. Tim -- Tim Hockin Systems Software Engineer Sun Microsystems, Cobalt Server Appliances [EMAIL PROTECTED] diff -ruN dist-2.4.5/net/ipv4/tcp.c cobalt-2.4.5/net/ipv4/tcp.c --- dist-2.4.5/net/ipv4/tcp.c Wed May 16 10:31:27 2001 +++ cobalt-2.4.5/net/ipv4/tcp.c Thu May 31 14:33:23 2001 @@ -2138,6 +2138,7 @@ tp->accept_queue_tail = NULL; newsk = req->sk; + newsk->rcv_saddr = req->af.v4_req.loc_addr; tcp_acceptq_removed(sk); tcp_openreq_fastfree(req); BUG_TRAP(newsk->state != TCP_SYN_RECV);
[PATCH] sym53c8xx timer and smp fixes
All,
Attached is a patch for sym53c8xx.c to handle the error timer better, and
be more proper for SMP. The changes are very simple, and have been beaten
on by us. Please let me know if there are any problems accepting this
patch for general inclusion.
Tim
--
Tim Hockin
Systems Software Engineer
Sun Microsystems, Cobalt Server Appliances
[EMAIL PROTECTED]
diff -ruN dist-2.4.5/drivers/scsi/sym53c8xx.c cobalt-2.4.5/drivers/scsi/sym53c8xx.c
--- dist-2.4.5/drivers/scsi/sym53c8xx.c Fri Apr 27 13:59:19 2001
+++ cobalt-2.4.5/drivers/scsi/sym53c8xx.c Thu May 31 14:32:43 2001
@@ -634,8 +636,11 @@
#if LINUX_VERSION_CODE >= LinuxVersionCode(2,1,93)
spinlock_t sym53c8xx_lock = SPIN_LOCK_UNLOCKED;
+spinlock_t sym53c8xx_host_lock = SPIN_LOCK_UNLOCKED;
#defineNCR_LOCK_DRIVER(flags) spin_lock_irqsave(_lock, flags)
#defineNCR_UNLOCK_DRIVER(flags)
spin_unlock_irqrestore(_lock,flags)
+#defineNCR_LOCK_HOSTS(flags) spin_lock_irqsave(_host_lock,
+flags)
+#defineNCR_UNLOCK_HOSTS(flags)
+spin_unlock_irqrestore(_host_lock,flags)
#define NCR_INIT_LOCK_NCB(np) spin_lock_init(>smp_lock);
#defineNCR_LOCK_NCB(np, flags)spin_lock_irqsave(>smp_lock, flags)
@@ -650,6 +655,8 @@
#defineNCR_LOCK_DRIVER(flags) do { save_flags(flags); cli(); } while (0)
#defineNCR_UNLOCK_DRIVER(flags) do { restore_flags(flags); } while (0)
+#defineNCR_LOCK_HOSTS(flags) do { save_flags(flags); cli(); } while (0)
+#defineNCR_UNLOCK_HOSTS(flags) do { restore_flags(flags); } while (0)
#defineNCR_INIT_LOCK_NCB(np) do { } while (0)
#defineNCR_LOCK_NCB(np, flags)do { save_flags(flags); cli(); } while (0)
@@ -695,7 +702,7 @@
return page_remapped? (page_remapped + page_offs) : 0UL;
}
-static void __init unmap_pci_mem(u_long vaddr, u_long size)
+static void unmap_pci_mem(u_long vaddr, u_long size)
{
if (vaddr)
iounmap((void *) (vaddr & PAGE_MASK));
@@ -2249,7 +2265,6 @@
**
*/
struct usrcmd user; /* Command from user*/
- volatile u_char release_stage; /* Synchronisation stage on release */
/*
** Fields that are used (primarily) for integrity check
@@ -5868,7 +5883,12 @@
** start the timeout daemon
*/
np->lasttime=0;
- ncr_timeout (np);
+#ifdef SCSI_NCR_PCIQ_BROKEN_INTR
+ np->timer.expires = ktime_get((HZ+9)/10);
+#else
+ np->timer.expires = ktime_get(SCSI_NCR_TIMER_INTERVAL);
+#endif
+ add_timer(>timer);
/*
** use SIMPLE TAG messages by default
@@ -7227,23 +7247,19 @@
**==
*/
-#ifdef MODULE
static int ncr_detach(ncb_p np)
{
- int i;
+ unsigned long flags;
printk("%s: detaching ...\n", ncr_name(np));
/*
-** Stop the ncr_timeout process
-** Set release_stage to 1 and wait that ncr_timeout() set it to 2.
+** Stop the ncr_timeout process - lock it to ensure no timer is running
+** on a different CPU, or anything
*/
- np->release_stage = 1;
- for (i = 50 ; i && np->release_stage != 2 ; i--) MDELAY (100);
- if (np->release_stage != 2)
- printk("%s: the timer seems to be already stopped\n",
- ncr_name(np));
- else np->release_stage = 2;
+ NCR_LOCK_NCB(np, flags);
+ del_timer(>timer);
+ NCR_UNLOCK_NCB(np, flags);
/*
** Reset NCR chip.
@@ -7273,7 +7289,6 @@
return 1;
}
-#endif
/*==
**
@@ -8600,23 +8615,11 @@
{
u_long thistime = ktime_get(0);
- /*
- ** If release process in progress, let's go
- ** Set the release stage from 1 to 2 to synchronize
- ** with the release process.
- */
-
- if (np->release_stage) {
- if (np->release_stage == 1) np->release_stage = 2;
- return;
- }
-
#ifdef SCSI_NCR_PCIQ_BROKEN_INTR
- np->timer.expires = ktime_get((HZ+9)/10);
+ mod_timer(>timer, ktime_get((HZ+9)/10));
#else
- np->timer.expires = ktime_get(SCSI_NCR_TIMER_INTERVAL);
+ mod_timer(>timer, ktime_get(SCSI_NCR_TIMER_INTERVAL));
#endif
- add_timer(>timer);
/*
** If we are resetting the ncr, wait for settle_time before
@@ -13071,7 +13075,7 @@
(int) (PciDeviceFn(pdev) & 7));
#ifdef SCSI_NCR_DYNAMIC_DMA_MAPPING
- if (pci_set_dma_mask(pdev, (dma_addr_t) (0xUL))) {
+ if (!pci_dma_supported(pdev, (dma_addr_t) (0xUL))) {
printk(KERN_WARNING NAME53C8XX
"32 BIT PCI BUS DMA ADDRESSING NOT SUPPORTED\n");
return -1;
@@ -14181,13
[PATCH] IDE GET/SET_BUSSTATE ioctls
Andre,
We spoke a while back about a GET/SET BUSSTATE API for IDE. Attached is my
(very simple) patch adding 2 ioctls, and obsoleting 1. I will send the
implementation of this for the HPT370 in a different message. Please let
me know if there are any problems with this preventing general inclusion.
This patch also includes support for a configurable 'max failures'
parameter, and one change for better DMA error reporting.
Tim
Andre Hedrick wrote:
>
> Bring it on! ;-)
>
> On Tue, 27 Mar 2001, Tim Hockin wrote:
>
> > Andre,
> >
> > I'm doing some work toward hotswap IDE, and I had a query for you. On
> > 2.2.x we added a HDIO_GET_BUSSTATE and HDIO_SET_BUSSTATE ioctl() pair. Now
> > I see in 2.4 that there is an HDIO_TRISTATE_HWIF ioctl(), but no way to
> > un-tristate or query the status.
> >
> > Are there plans to add the converse APIs? I see no one has yet implemented
> > the HWIF_TRISTATE_BUS ioctl() - would you accept my patch to
> > implement the HDIO_{GET,SET}_BUSSTATE, and implementation of it on the
> > HPT366 driver?
--
Tim Hockin
Systems Software Engineer
Sun Microsystems, Cobalt Server Appliances
[EMAIL PROTECTED]
diff -ruN dist-2.4.5/include/linux/hdreg.h cobalt-2.4.5/include/linux/hdreg.h
--- dist-2.4.5/include/linux/hdreg.hFri May 25 18:01:27 2001
+++ cobalt-2.4.5/include/linux/hdreg.h Thu May 31 14:33:16 2001
@@ -181,9 +181,10 @@
#define HDIO_GET_DMA 0x030b /* get use-dma flag */
#define HDIO_GET_NICE 0x030c /* get nice flags */
#define HDIO_GET_IDENTITY 0x030d /* get IDE identification info */
+#define HDIO_GET_BUSSTATE 0x030e /* get the bus state of the hwif */
#define HDIO_DRIVE_RESET 0x031c /* execute a device reset */
-#define HDIO_TRISTATE_HWIF 0x031d /* execute a channel tristate */
+#define HDIO_TRISTATE_HWIF 0x031d /* OBSOLETE - use SET_BUSSTATE */
#define HDIO_DRIVE_TASK0x031e /* execute task and special drive
command */
#define HDIO_DRIVE_CMD 0x031f /* execute a special drive command */
@@ -200,6 +201,14 @@
#define HDIO_SCAN_HWIF 0x0328 /* register and (re)scan interface */
#define HDIO_SET_NICE 0x0329 /* set nice flags */
#define HDIO_UNREGISTER_HWIF 0x032a /* unregister interface */
+#define HDIO_SET_BUSSTATE 0x032b /* set the bus state of the hwif */
+
+/* bus states */
+enum {
+ BUSSTATE_OFF = 0,
+ BUSSTATE_ON,
+ BUSSTATE_TRISTATE
+};
/* BIG GEOMETRY */
struct hd_big_geometry {
diff -ruN dist-2.4.5/include/linux/ide.h cobalt-2.4.5/include/linux/ide.h
--- dist-2.4.5/include/linux/ide.h Fri May 25 18:02:42 2001
+++ cobalt-2.4.5/include/linux/ide.hThu May 31 14:33:16 2001
@@ -349,6 +350,8 @@
byteinit_speed; /* transfer rate set at boot */
bytecurrent_speed; /* current transfer rate set */
bytedn; /* now wide spread use */
+ unsigned intfailures; /* current failure count */
+ unsigned intmax_failures; /* maximum allowed failure count */
} ide_drive_t;
/*
@@ -397,6 +400,11 @@
typedef void (ide_rw_proc_t) (ide_drive_t *, ide_dma_action_t);
/*
+ * ide soft-power support
+ */
+typedef int (ide_busproc_t) (struct hwif_s *, int);
+
+/*
* hwif_chipset_t is used to keep track of the specific hardware
* chipset used by each IDE interface, if known.
*/
@@ -467,6 +475,8 @@
#endif
bytestraight8; /* Alan's straight 8 check */
void*hwif_data; /* extra hwif data */
+ ide_busproc_t *busproc; /* driver soft-power interface */
+ bytebus_state; /* power state of the IDE bus */
} ide_hwif_t;
diff -ruN dist-2.4.5/drivers/ide/ide.c cobalt-2.4.5/drivers/ide/ide.c
--- dist-2.4.5/drivers/ide/ide.cTue May 1 16:05:00 2001
+++ cobalt-2.4.5/drivers/ide/ide.c Thu May 31 14:32:16 2001
@@ -161,6 +161,9 @@
#include
#endif /* CONFIG_KMOD */
+/* default maximum number of failures */
+#define IDE_DEFAULT_MAX_FAILURES 1
+
static const byte ide_hwif_to_major[] = { IDE0_MAJOR, IDE1_MAJOR, IDE2_MAJOR,
IDE3_MAJOR, IDE4_MAJOR, IDE5_MAJOR, IDE6_MAJOR, IDE7_MAJOR, IDE8_MAJOR, IDE9_MAJOR };
static int idebus_parameter; /* holds the "idebus=" parameter */
@@ -248,6 +251,7 @@
hwif->name[1] = 'd';
hwif->name[2] = 'e';
hwif->name[3] = '0' + index;
+ hwif->bus_state = BUSSTATE_ON;
for (unit = 0; unit < MAX_DRIVES; ++unit) {
ide_drive_t *drive = >drives[unit];
@@ -262,6 +266,7 @@
drive->name[0] = 'h';
drive->name[1] = 'd';
drive->name[2] = 'a' + (index * MAX_DRIVES) + unit;
+ drive->max_failures = IDE_DEFAULT_MAX_FAILURES;
init_waitqueue_head(>wqueue);
}
}
@@ -636,11 +641,14 @@
return
[PATCH] new PCI ids
Attached is a patch for cleaning up some PCI ids and adding a few that were missing. Please let me know of any problems with this. (diff against 2.4.5) Tim -- Tim Hockin Systems Software Engineer Sun Microsystems, Cobalt Server Appliances [EMAIL PROTECTED] diff -ruN dist-2.4.5/drivers/pci/pci.ids cobalt-2.4.5/drivers/pci/pci.ids --- dist-2.4.5/drivers/pci/pci.ids Sat May 19 17:49:14 2001 +++ cobalt-2.4.5/drivers/pci/pci.idsThu May 31 14:32:33 2001 @@ -4,7 +4,7 @@ # Maintained by Martin Mares <[EMAIL PROTECTED]> # If you have any new entries, send them to the maintainer. # -# $Id: pci.ids,v 1.62 2000/06/28 10:56:36 mj Exp $ +# $Id: pci.ids,v 1.3 2001/04/04 20:40:25 thockin Exp $ # # Vendors, devices and subsystems. Please keep sorted. @@ -244,6 +244,7 @@ 000f OHCI Compliant FireWire Controller 0011 National PCI System I/O 0012 USB Controller + 0020 DP83815 (MacPhyter) Ethernet Controller d001 87410 IDE 100c Tseng Labs Inc 3202 ET4000/W32p rev A @@ -1925,9 +1926,9 @@ 1102 8051 CT4850 SBLive! Value 7002 SB Live! 1102 0020 Gameport Joystick -1103 Triones Technologies, Inc. - 0003 HPT343 - 0004 HPT366 +1103 HighPoint Technologies, Inc. + 0003 HPT343 UltraDMA 33 IDE Controller + 0004 HPT366/370 UltraDMA 66/100 IDE Controller 1104 RasterOps Corp. 1105 Sigma Designs, Inc. 8300 REALmagic Hollywood Plus DVD Decoder @@ -2335,13 +2336,16 @@ 1165 Imagraph Corporation 0001 Motion TPEG Recorder/Player with audio 1166 ServerWorks - 0007 CNB20-LE CPU to PCI Bridge - 0008 CNB20HE - 0009 CNB20LE + 0007 CNB20-LE Host Bridge + 0008 CNB20HE Host Bridge + 0009 CNB20LE Host Bridge 0010 CIOB30 0011 CMIC-HE - 0200 OSB4 - 0201 CSB5 + 0200 OSB4 South Bridge + 0201 CSB5 South Bridge + 0211 OSB4 IDE Controller + 0212 CSB5 IDE Controller + 0220 OSB4/CSB5 OHCI USB Controller 1167 Mutoh Industries Inc 1168 Thine Electronics Inc 1169 Centre for Development of Advanced Computing diff -ruN dist-2.4.5/include/linux/pci_ids.h cobalt-2.4.5/include/linux/pci_ids.h --- dist-2.4.5/include/linux/pci_ids.h Wed May 16 10:25:39 2001 +++ cobalt-2.4.5/include/linux/pci_ids.hThu May 31 14:33:17 2001 @@ -991,10 +991,12 @@ #define PCI_DEVICE_ID_SERVERWORKS_LE 0x0009 #define PCI_DEVICE_ID_SERVERWORKS_CIOB30 0x0010 #define PCI_DEVICE_ID_SERVERWORKS_CMIC_HE 0x0011 -#define PCI_DEVICE_ID_SERVERWORKS_CSB50x0201 #define PCI_DEVICE_ID_SERVERWORKS_OSB4 0x0200 +#define PCI_DEVICE_ID_SERVERWORKS_CSB5 0x0201 #define PCI_DEVICE_ID_SERVERWORKS_OSB4IDE 0x0211 +#define PCI_DEVICE_ID_SERVERWORKS_CSB5IDE 0x0212 #define PCI_DEVICE_ID_SERVERWORKS_OSB4USB 0x0220 +#define PCI_DEVICE_ID_SERVERWORKS_CSB5USB PCI_DEVICE_ID_SERVERWORKS_OSB4USB #define PCI_VENDOR_ID_SBE 0x1176 #define PCI_DEVICE_ID_SBE_WANXL100 0x0301
Re: udp server in kernel mode
I think this example would be help. Linux Magazine December 2000 The Design of an In-Kernel Server by Alessandro Rubini http://www.linux-mag.com/2000-12/gear_01.html *=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=* Lee, Ho. Software Engineer, Embedded Linux Dep, LinuxOne ICQ : #52017992, Mail : [EMAIL PROTECTED], [EMAIL PROTECTED] Homepage : http://flyduck.com, http://linuxkernel.to Angela Picariello Wrote: >I'm implementing a server udp in kernel mode. >I've many difficult to find an example. > >I've kernel version 2.2.16. > >(Anyway I accept every suggest). > >Can you help me? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] 66MHz PCI flag from commandline
Martin,
We spoke a while back about a pcispeed= command line param to set the PCI
busspeed values (for later querying, if needed). Attached is my patch to
implement the feature we agreed upon. It is against linux-2.4.5.
Below is our previous discussion, as a refresher :). Please let me know if
this is not suitable for general inclusion in the kernel, and I'll try to
make it so.
Tim
(cc: lkml, alan)
Martin Mares wrote:
> > What do you think of my pcispeed=0:33,2:66 idea?
> anything -- the 33/66 MHz values from the PCI specs are only upper limits),
> I'll welcome this option, but otherwise I'd rather like to use the measuring
> code in IDE driver as it requires no user intervention to get the right
> timing.
--
Tim Hockin
Systems Software Engineer
Sun Microsystems, Cobalt Server Appliances
[EMAIL PROTECTED]
diff -ruN dist-2.4.5/drivers/pci/pci.c cobalt-2.4.5/drivers/pci/pci.c
--- dist-2.4.5/drivers/pci/pci.cSat May 19 17:43:06 2001
+++ cobalt-2.4.5/drivers/pci/pci.c Thu May 31 14:32:33 2001
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
#include /* for hotplug_path */
#include
@@ -37,6 +38,8 @@
LIST_HEAD(pci_root_buses);
LIST_HEAD(pci_devices);
+static int get_bus_speed(struct pci_bus *bus);
+
/**
* pci_find_slot - locate PCI device from a given PCI slot
* @bus: number of PCI bus on which desired PCI device resides
@@ -928,6 +931,7 @@
child->number = child->secondary = busnr;
child->primary = parent->secondary;
child->subordinate = 0xff;
+ child->bus_speed = get_bus_speed(child);
/* Set up default resource pointers.. */
for (i = 0; i < 4; i++)
@@ -1110,8 +1114,19 @@
return NULL;
/* some broken boards return 0 or ~0 if a slot is empty: */
- if (l == 0x || l == 0x || l == 0x || l == 0x)
+ if (l == 0x || l == 0x
+|| l == 0x || l == 0x) {
+ /*
+* host/pci and pci/pci bridges will set Received Master Abort
+* (bit 13) on failed configuration access (happens when
+* searching for devices). To be safe, clear the status
+* register.
+*/
+ unsigned short st;
+ pci_read_config_word(temp, PCI_STATUS, );
+ pci_write_config_word(temp, PCI_STATUS, st);
return NULL;
+ }
dev = kmalloc(sizeof(*dev), GFP_KERNEL);
if (!dev)
@@ -1239,6 +1254,7 @@
list_add_tail(>node, _root_buses);
b->number = b->secondary = bus;
+ b->bus_speed = get_bus_speed(b);
b->resource[0] = _resource;
b->resource[1] = _resource;
return b;
@@ -1739,7 +1755,66 @@
return 1;
}
+#define MAX_OVERRIDES 256
+static int pci_speed_overrides[MAX_OVERRIDES] __initdata;
+
+static int __init get_bus_speed(struct pci_bus *bus)
+{
+ if (!bus) {
+ return -1;
+ }
+
+ if (pci_speed_overrides[bus->number]) {
+ return pci_speed_overrides[bus->number];
+ } else {
+ /* printk("PCI: assuming 33 MHz for bus %d\n", bus->number); */
+ return 33;
+ }
+}
+
+/* handle pcispeed=0:33,1:66 parameter (speed=0 means unknown) */
+static int __init pci_speed_setup(char *str)
+{
+while (str) {
+char *k = strchr(str, ',');
+if (k) {
+*k++ = '\0';
+ }
+
+if (*str) {
+int bus;
+int speed;
+char *endp;
+
+ if (!isdigit(*str)) {
+ printk("PCI: bad bus number for "
+ "pcispeed parameter\n");
+ str = k;
+ continue;
+ }
+bus = simple_strtoul(str, , 0);
+
+if (!*endp || !isdigit(*(++endp))) {
+ printk("PCI: bad speed for "
+ "pcispeed parameter\n");
+ str = k;
+ continue;
+ }
+ speed = simple_strtoul(endp, NULL, 0);
+ pci_speed_overrides[bus] = speed;
+ printk("PCI: setting bus %d speed to %d MHz\n",
+ bus, speed);
+
+ str = k;
+ } else {
+ break;
+ }
+ }
+ return 1;
+}
+
__setup("pci=", pci_setup);
+__setup("pcispeed=", pci_speed_setup);
EXPORT_SYMBOL(pci_read_config_byte);
diff -ruN dist-2.4.5/include/linux/pci.h cobalt-2.4.5/include/linux/pci.h
--- dist-2.4.5/include/linux/pci.h Fri May 25 18:02:11 2001
+++ cobalt-2.4.5/include/linux/pci.h
Re: 2.4.5 VM
Actually I take everything back. I've been testing on linux-2.4.5-xfs and seen major improvements. -zim Christopher Zimmerman wrote: > Christopher Zimmerman wrote: > > > "Trever L. Adams" wrote: > > > > > In my opinion 2.4.x is NOT ready for primetime. The VM has been getting > > > worse since 2.4.0, I believe. Definitely since and including 2.4.3. I > > > cannot even edit a few images in gimp where the entire working set used > > > to fit entirely in memory. The system now locks in some loop (SAK still > > > works). > > > > > > FILE CACHING IS BROKEN. I don't care who says what, by the time swap is > > > half filled, it is time to start throwing away simple caches. Not wait > > > until there is no more memory free and then lock in an infinite loop. > > > > > > My system has 128 Meg of Swap and RAM. > > > > > > Trever Adams > > > > > > - > > > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > > > the body of a message to [EMAIL PROTECTED] > > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > > Please read the FAQ at http://www.tux.org/lkml/ > > > > I've found that with the latest kernel release (2.4.5) VM performance has > > been greatly improved. kswapd and bdflush no longer use 200% of my cpu > > cycles when simply doing a dd bs=1024 count=8388608 if=/dev/zero > > of=test.file. All of my test systems remain responsive with about 180% cpu > > available. These systems are running software RAID and 3ware IDE raid with > > 2GB of memory and 4GB swap. Have you tried 2.4.5? > > > > -zim > > > > Christopher Zimmerman > > AltaVista Company > > > > - > > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > > the body of a message to [EMAIL PROTECTED] > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.5 VM
Christopher Zimmerman wrote: > "Trever L. Adams" wrote: > > > In my opinion 2.4.x is NOT ready for primetime. The VM has been getting > > worse since 2.4.0, I believe. Definitely since and including 2.4.3. I > > cannot even edit a few images in gimp where the entire working set used > > to fit entirely in memory. The system now locks in some loop (SAK still > > works). > > > > FILE CACHING IS BROKEN. I don't care who says what, by the time swap is > > half filled, it is time to start throwing away simple caches. Not wait > > until there is no more memory free and then lock in an infinite loop. > > > > My system has 128 Meg of Swap and RAM. > > > > Trever Adams > > > > - > > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > > the body of a message to [EMAIL PROTECTED] > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > Please read the FAQ at http://www.tux.org/lkml/ > > I've found that with the latest kernel release (2.4.5) VM performance has > been greatly improved. kswapd and bdflush no longer use 200% of my cpu > cycles when simply doing a dd bs=1024 count=8388608 if=/dev/zero > of=test.file. All of my test systems remain responsive with about 180% cpu > available. These systems are running software RAID and 3ware IDE raid with > 2GB of memory and 4GB swap. Have you tried 2.4.5? > > -zim > > Christopher Zimmerman > AltaVista Company > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Configure.help is complete
On Thursday, 31 May 2001, at 14:23:21 -0400, Eric S. Raymond wrote: > José Luis Domingo López <[EMAIL PROTECTED]>: > > Would it be great to have a similar documentation for those hundreds of > > "files" under /proc ?. > > Yes, this would be wonderful. Are you volunteering to write it? > I'm not skilled enough to write even simple C or PERL programs, but maybe I could try improving linux kernel documentation. Not sure about the procedure to take nor the available time I'll have. But I'm willing to help where I can. Would be nice to know whether there is some sense in documenting the whole /proc, just the part of ot that will stay in 2.5.x or continue with what we have rught now. I'll check the mentioned program to see if there is the information I need. Stay tuned :) Regards. -- José Luis Domingo López Linux Registered User #189436 Debian GNU/Linux Potato (P166 64 MB RAM) jdomingo EN internautas PUNTO org => ¿ Spam ? Atente a las consecuencias jdomingo AT internautas DOT org => Spam at your own risk - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: missing sysrq
Bernd Eckenfels wrote: > > In article <[EMAIL PROTECTED]> you wrote: > > However, if I go to /proc/sys/kernel/sysrq does not exist. > > It is a compile time option, so the person who compiled your kernel left it > out. I compiled it, and the sysrq is definitely in the config. No doubt at all. I also use make mrproper and config again before dep and actual compile. Maybe it is just a quirk/oddball. D. Stimits, [EMAIL PROTECTED] > > > vm.freepages = 383 766 1149 > > tat feature is removed in recent VM Systems. > > Greetings > Bernd > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.5 VM
Christopher Zimmerman wrote: > > I've found that with the latest kernel release (2.4.5) VM performance has > been greatly improved. kswapd and bdflush no longer use 200% of my cpu > cycles when simply doing a dd bs=1024 count=8388608 if=/dev/zero > of=test.file. All of my test systems remain responsive with about 180% cpu > available. These systems are running software RAID and 3ware IDE raid with > 2GB of memory and 4GB swap. Have you tried 2.4.5? > > -zim > > Christopher Zimmerman > AltaVista Company > I have found that 2.4.5 is great, until it decides to stop freeing unused pages (simple file cache). Then it goes to hell in a handbasket at the speed of light. Yes, I have tried it, that is what I wrote about. Trever - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: your mail
Followup to: <[EMAIL PROTECTED]> By author:Andrzej Krzysztofowicz <[EMAIL PROTECTED]> In newsgroup: linux.dev.kernel > > BTW, linux-kernel readers: anybody is a volunteer for making the kernel size > counter 32-bit here? This would enable using the simple bootloader for > greater kernel loading... (current limit is sligtly below 1MB) > Possibly some 16/32-bit real mode code mixing would be necessary. > PLEASE don't go there. bootsect.S is fundamentally broken these days (doesn't work on USB floppies, for example.) It should be killed DEAD, DEAD, DEAD and not dragged along like a dead albatross. -hpa -- <[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.5 VM
"Trever L. Adams" wrote: > In my opinion 2.4.x is NOT ready for primetime. The VM has been getting > worse since 2.4.0, I believe. Definitely since and including 2.4.3. I > cannot even edit a few images in gimp where the entire working set used > to fit entirely in memory. The system now locks in some loop (SAK still > works). > > FILE CACHING IS BROKEN. I don't care who says what, by the time swap is > half filled, it is time to start throwing away simple caches. Not wait > until there is no more memory free and then lock in an infinite loop. > > My system has 128 Meg of Swap and RAM. > > Trever Adams > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ I've found that with the latest kernel release (2.4.5) VM performance has been greatly improved. kswapd and bdflush no longer use 200% of my cpu cycles when simply doing a dd bs=1024 count=8388608 if=/dev/zero of=test.file. All of my test systems remain responsive with about 180% cpu available. These systems are running software RAID and 3ware IDE raid with 2GB of memory and 4GB swap. Have you tried 2.4.5? -zim Christopher Zimmerman AltaVista Company - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[QUESTION] which routines must be re-entrant?
Is there an easy way to tell which routines must be re-entrant? (it doesn't have to be exhaustive, even an incomplete set is useful) I was going to write a checker to make sure supposedly re-entrant routines actually were, but was having a hard time figuring out which ones were supposed to be... Thanks, Dawson - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.5 VM
> Actually I have tried 1x,2x,3x. In 2.4.0 to 2.4.3 I had some issues but > never a system freeze of any kind. With 2.4.4 I had more problems, but > I was ok. 2.4.5 I now have these freezes. Maybe I should go back to > 2x, but I still find this behavior crazy. > This still doesn't negate the point of freeing simple caches. The caches are in part shared. Remember page cache memory and read only application pages are the same thing - so its not that simple. I found 2.4.5 pretty bad. 2.4.5-ac seems to be better on the whole but I know its definitely not right yet. Marcelo and Rik are working on that more and more. Marcelo has a test patch to fix the (documented but annoying) 2x memory swap rule stuff. The balancing problem is harder but being worked on. If you can give Rik a summary of your config/what apps run/ps data then it may be valuable as he can duplicate your exact setup for testing his vm changes and add it to the test sets. Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Emu10k1-devel] Re: how to crash 2.4.4 w/SBLive
Great, No more oops. Thanks On Thursday, 31 May 2001, at 20:33:54 (+0200), [EMAIL PROTECTED] wrote: > On Thu, 31 May 2001, David Raufeisen wrote: > > But now it progressed a bit more ;) > > New patch attached. > -- David Raufeisen <[EMAIL PROTECTED]> Cell: (604) 818-3596 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.5 VM
> My system has 128 Meg of Swap and RAM. Linus 2.4.0 notes are quite clear that you need at least twice RAM of swap with 2.4. Marcelo is working to change that but right now you are running something explicitly explained as not going to work as you want - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AT keyboard optional on i386?
On Tue, 29 May 2001, Pavel Roskin wrote: >> You can a few nice tricks with it like plug in two PS/2 keyboards. I >> have this for my home setup. The only thing is make sure you don't >> have both keyboards plugged in when you turn your PC on. I found BIOS >> get confused by two PS/2 keyboards. As you can it is very easy to >> multiplex many keyboards with the above design. I have had 4 different >> keyboards hooked up to my system and functioning at the same time. We >> even got a Sun keyboard to work on a intel box :-) > >That's what we like Linux for. It doesn't get confused when everything >else does :-) Heh, that's funny. I must admit I'd never thought of that. Anyway, the bios gets confused because it's trying to figure out (in a very simple way) where the keyboard and mouse are. It's true there's lots of voodoo in PC BIOSes; keyboard/mouse detection isn't one of them. (As I recall, I have to have something in the port to get it enabled. Linux doesn't seem to know how to enable it.) --Ricky - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.4.5 VM
In my opinion 2.4.x is NOT ready for primetime. The VM has been getting worse since 2.4.0, I believe. Definitely since and including 2.4.3. I cannot even edit a few images in gimp where the entire working set used to fit entirely in memory. The system now locks in some loop (SAK still works). FILE CACHING IS BROKEN. I don't care who says what, by the time swap is half filled, it is time to start throwing away simple caches. Not wait until there is no more memory free and then lock in an infinite loop. My system has 128 Meg of Swap and RAM. Trever Adams - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Ext2-devel] [UPDATE] Directory index for ext2
Daniel writes: > On Thursday 31 May 2001 21:44, Andreas Dilger wrote: > > I think Al's idea of doing the validation once on the initial > > read is a good one. > > I'm doing that in the current patch, for leaf blocks, look at > ext2_bread. For index blocks, ext2_bread needs help to know that a > block is supposed to be an index block. Add a parameter? I think we should just get rid of the misconception that ext2_bread() is a block read function. It is only used by directory functions. Instead we should have separate ext2_bread_leaf(), ext2_bread_root(), ext2_bread_node() which do the appropriate validation for each type of block. In ext2_bread_dir() if we really think directory block prealloc is a win (in addition to the existing in-memory contiguous block prealloc), we may as well do it each time we split a leaf block, and make them valid in-use leaf blocks instead of just wasting space on disk (i.e. each split block has the hash space split into 1/N of the existing space, and we distribute existing entries across all N blocks). This way we don't have to split the each directory block so many times. For indexed directories this is (probably) a net win because we avoid N extra block splits (i.e. extra copying of leaf blocks), and make the leaf search space smaller. On non-indexed ext2 it would be a net loss because we would still have to read and search each directory block, even if they are empty. > It's normal for it to start by putting all the entries into the first > two blocks, but after those are split it should be pretty uniform > across the resulting 4, and so on. Can you confirm it's unbalanced? I don't think that is what I was seeing, because the hash block numbers were not "->1" and "->2" (which would be the case right after a split), but rather 30's, 40's, etc. > > Running mongo has shown up another bug, I see, but haven't had a > > chance to look into yet. It involves not being able to delete files > > from an indexed directory: > > > > rm: cannot remove `/mnt/tmp/testdir1-0-0/d0/d1/d2/d3/509.r': > > Input/output error > > > > This is after the files had been renamed (.r suffix). Do we re-hash > > directory entries if the file is renamed? If not, then that would > > explain this problem. It _looks_ like we do the right thing, but the > > mongo testing wipes out the filesystem after each test, and the above > > message is from a logfile only. > > The rename creates the new entry via ext2_add_entry so the hash must be > correct. Time to get out the bug swatter. I'll get mongo and try it. One other point of information. In the test I was running, it was always the file "509.r" which had the I/O error (new filesystem each test run, btw, and no IDE errors in the log). 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-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: How to know HZ from userspace?
On Fri, 1 Jun 2001, Peter Waltenberg wrote: > Yes, I know we have a chance of being rescheduled simply because "something > else" has also yielded. However thats fairly hit and miss. > > I don't disagree with your statement that thats how the interface should be > designed, but the most of the apps that could use it still have an unreliable > interface. i.e. you ask to be woken in 2.54mS, on X86 it'll likely be ~10mS, > on Alpha ~3mS. Now and then you'll get woken somewhere near the time you > requested. > First of all, the unit of time is the second (s), not the siemens (S). Second, I think we're talking about different things. I'm talking about interfaces (/proc, ioctl, etc.) in which durations are specified in jiffies. This is unacceptable. What you seem to be talking about is user-space insight into the scheduling algorithm, which is another matter. -hpa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4 freezes on VIA KT133
It seems the problem is caused by some DMA related bug in the VIA chipset and/or in the Linux DMA-IDE VIA driver. I finnaly get rid of the freezes, by simply compiling the kernel completely without IDE-DMA support. Now hdparm shows disks do not use DMA and the system is stable, as far as I can say now. I've tested it VERY intensely last couple of days and did not manage to freeze it. For 12 hours a lot of concurrent processes copied gigs of data all over the disks, calculated CPU intensive crypto etc, the system hasn't frozen. For debugging purposes I also tried to downgrade to 2.2.19 with IDE-DMA activated. It crashed. So it really seems DMA is the problem here. Maybe I did not describe the freezes accurately in my first post. After the freeze, the screen always went black, and the system was dead - did not respond to pings, keyboard etc. It was neccessary to hard reset it. Tomas - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: no sound with CS4281 card
I Can not reproduce the problem with 2.4.5-ac5 driver or with latest rev of the driver that I have been working on, or with any of the previous 4 internal releases back to early april. although I do not have a Toshiba laptop to test on and don't doubt that there might be a problem on your system. I have not tested a 1755 model. Another user indicated that the Toshiba 1620 CDS works with the latest driver. I'll wait for your input concerning the latest driver that I sent to you via email. Fyi, I have USB disabled, SMP enabled, and all *PM enabled. If you can boot with max debugging /sbin/insmod cs4281.o cs_debuglevel=9 cs_debugmask=0x and then run mpg123 on a very small mp3 file or very small wave file (<16k). It'll be a lot of output, but if you could send it all, especially the boot info, that'd help me to debug the problem. Thanks tom -Original Message- From: Rik van Riel [mailto:[EMAIL PROTECTED]] Sent: Thursday, May 31, 2001 1:15 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject:no sound with CS4281 card Hi, my notebook (Toshiba 1755) comes with CS4281 built-in, with all 2.4 kernels I tried this sound card doesn't generate any sound, or interrupts for that matter. The driver detects the card fine, but doesn't seem to be able to do anything with it, on 2.4.5-ac2: /proc/pci Bus 0, device 8, function 0: Multimedia audio controller: Cirrus Logic Crystal CS4281 PCI Audio (rev 1). IRQ 5. Master Capable. Latency=64. Min Gnt=4.Max Lat=24. Non-prefetchable 32 bit memory at 0xfc01 [0xfc010fff]. Non-prefetchable 32 bit memory at 0xfc00 [0xfc00]. dmesg cs4281: version v1.13.32 time 15:54:07 May 29 2001 PCI: Enabling device 00:08.0 ( -> 0002) PCI: Found IRQ 5 for device 00:08.0 /proc/interrupts 5: 0 XT-PIC Crystal CS4281 (after trying to play music with mpg123 about 20 times) regards, Rik -- Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://distro.conectiva.com/ Send all your spam to [EMAIL PROTECTED] (spam digging piggy) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [CHECKER] 2.4.5-ac4 non-init functions calling init functions
> These are actual (performance) bugs. > Patch is appended. Thanks for the quick feedback! > BTW: I don't if you did so already, but if you extended the checker to > find functions which are only called from __init functions, but not > marked __init themselves, you'd most likely find lots more performance > bugs of this kind. I haven't hacked this in --- I was waiting to get a feel for how important the checker was before spending too much time on it. I agree with your intuition that there would be a lot of these cases ;-) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: unmount issues with 2.4.5-ac5, 3ware, and ReiserFS (was: kernel-2.4.5
Alan Cox wrote: > > > I'm staying on 2.4.5-ac5 for whatever it's worth (putting my life on the > > line for the community? kidding...) and will report anything new. I will > > be on the lookout for later ac patches, 2.4.6 ... and hopefully anything > > anybody can share with me about this. I hope we'll see an end to these > > Can you tell me if 2.4.5-ac4 is ok. ac5 has a small 'obviously correct' > reiserfs module unload change that seems the first suspect > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ I have seen this same problem with unmounting in 2.4.5-ac5, it was perfectly fine in 2.4.5-ac3 and ac4. I would guess the module unload is what did it. Jordan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: your mail
> > Minor issue with bootsect.s. 1. bootsect.S is the source file > The single instance of the lds assembly instruction includes the comment of > ! ds:si is source > ... > seg fs > lds si,(bx)! ds:si is source > ... > Is this comment not in reverse order (i.e should be lds > dest,src) 2. This is not a comment of i386 mnemonics. This comments the role of specific register in the following instructions. BTW, linux-kernel readers: anybody is a volunteer for making the kernel size counter 32-bit here? This would enable using the simple bootloader for greater kernel loading... (current limit is sligtly below 1MB) Possibly some 16/32-bit real mode code mixing would be necessary. Andrzej - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: missing sysrq
In article <[EMAIL PROTECTED]> you wrote: > However, if I go to /proc/sys/kernel/sysrq does not exist. It is a compile time option, so the person who compiled your kernel left it out. > vm.freepages = 383 766 1149 tat feature is removed in recent VM Systems. Greetings Bernd - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] net #6
> > They are done this way to get good non SMP performance. Your changes would > > ruin that. > > Maybe macro "spin_lock_irqsave_on_smp()" would be good idea? These > ifdefs look ugly. Maybe local to driver, maybe even global. I had that argument with Linus about globally and ended up with ifdefs. I agree about locally - feel free - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Defragging/refragging IPv6 packets
Hello,
My name is Brad Chapman and I am currently attempting to port the
iptables ip_conntrack component of Netfilter to the IPv6 protocol. My
port is almost feature-complete, but I cannot figure out how to properly
defragment/refragment IPv6 packets. Also, I have written an IPv6 header
parsing function to grab headers from the IPv6 header chain. I would
appreciate some feedback on that as well. Below are some code examples.
DEFRAGGING PACKETS:
/* Returns defragged sk_buff, or NULL */
/* FIXME: is this the "right" way to do it? -- BC */
struct sk_buff *ip6_ct_gather_frags(struct sk_buff *skb)
{
#ifdef CONFIG_NETFILTER_DEBUG
unsigned int old_debug = skb->nf_debug;
#endif
struct frag_hdr *fhdr = (struct frag_hdr *)
ipv6_get_header(skb->nh.ipv6h,
NEXTHDR_FRAGMENT,
NULL);
local_bh_disable();
if (!ipv6_reassembly(skb, (u8 *)fhdr))
return NULL;
local_bh_enable();
skb->nfcache |= NFC_ALTERED;
#ifdef CONFIG_NETFILTER_DEBUG
skb->nf_debug = old_debug;
#endif
return skb;
}
REFRAGGING PACKETS:
/* This gets the fragmentable part - I think -- BC */
static int ip6_refrag_getfrag(const void *data, struct in6_addr *addr,
char *buff, unsigned int offset, unsigned int len)
{
return 0;
}
static unsigned int ip6_refrag(unsigned int hooknum,
struct sk_buff **pskb,
const struct net_device *in,
const struct net_device *out,
int (*okfn)(struct sk_buff *))
{
struct frag_hdr *fhdr = (struct frag_hdr *)
ipv6_get_header((*pskb)->nh.ipv6h,
NEXTHDR_FRAGMENT,
NULL);
struct flowi *flow;
int ret;
__u8 protonum;
/* Verify the protocol */
if (!ipv6_get_header((*pskb)->nh.ipv6h, NEXTHDR_PROTOANY, ))
return NF_DROP;
/* We've seen it coming out the other side: confirm */
ip6_confirm(hooknum, pskb, in, out, okfn);
/* Local packets are never produced too large for their
interface. We degfragment them at LOCAL_OUT, however,
so we have to refragment them here. */
if ((fhdr) && !(fhdr->frag_off & htons(IP6_NON_FRAG_OFFSET))) {
/* Build the flowlabel */
flow.proto = (int)protonum;
ipv6_addr_copy(flow.fl6_src, (*pskb)->nh.ipv6h->saddr);
ipv6_addr_copy(flow.fl6_dst, (*pskb)->nh.ipv6h->daddr);
flow.fl6_flowlabel = 0;
if (protonum == NEXTHDR_TCP) {
flow.uli_u.ports.sport = (*pskb)->nh.tcph->sport;
flow.uli_u.ports.dport = (*pskb)->nh.tcph->dport;
}
else if (protonum == NEXTHDR_UDP) {
flow.uli_u.ports.sport = (*pskb)->nh.udph->sport;
flow.uli_u.ports.dport = (*pskb)->nh.udph->dport;
}
else if (protonum == NEXTHDR_ICMP) {
struct icmp6hdr *icmph;
icmph = (struct icmp6hdr *)ipv6_get_header((*pskb)->nh.ipv6h,
NEXTHDR_ICMP,
NULL);
if (!icmph)
return NF_DROP;
flow.uli_u.icmpt.type = icmph->icmp6_type;
flow.uli_u.icmpt.code = icmph->icmp6_code;
}
else
return NF_DROP;
ret = ip6_build_xmit((*pskb)->sk,
ip6_refrag_getfrag,
(*pskb)->data,
flow,
(*pskb)->nh.ipv6h->payload_len,
NULL, 0, 0);
if (ret < 0)
return NF_DROP;
return NF_STOLEN;
}
return NF_ACCEPT;
}
PARSING IPV6 HEADERS
/* Find a particular header in the IPv6 header chains */
struct ipv6_opt_hdr *
ipv6_get_header(const struct ipv6hdr *ipv6h,
__u8 header,
__u8 *result)
{
struct ipv6_opt_hdr *newhdr = NULL;
__u8 *hdrptr = (__u8 *)>nexthdr;
int hdrlen, length;
IP_NF_ASSERT(header != NEXTHDR_NONE);
IP_NF_ASSERT(*hdrptr != NEXTHDR_NONE);
/* Start bouncing */
length = sizeof(struct ipv6hdr);
hdrlen = 0;
while (*hdrptr !=
Re: Configure.help is complete
> Between SCSI and IEEE 1394; > Fusion MPT device support ---> doesn't lead anywhere. It does for me.. fusion requires scsi and experimental - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
include/asm-sparc/ptrace.h is broken
on line 76, it includes , which does not exist. This is critical because this include file does not work when used from a libc. ptrace.h is from 1997 on my 2.4.5 kernel, so this is not something that broke recently. My suggestion is to remove the offending line altogether or at least protect it with #ifdef __KERNEL__. Felix - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Ext2-devel] [UPDATE] Directory index for ext2
On Thursday 31 May 2001 21:44, Andreas Dilger wrote: > Daniel, you write: > > - Fall back to linear search in case of corrupted index > > OK, I have _some_ of the code needed to do this, but in one case I'm > not sure of what your intention was - in dx_probe() you check for > "unused_flags & 1" to signal a bad/unsupported index. Why only check > the low bit instead of the whole thing? I guess it really means I've allocated the low bit to mean 'incompatible change here, old code should give up now', so "unused_flags" is a misnomer. > I currently have: [code that kmail fsck'd completely in the quote] I'll incorporate it. > On lookup it is OK to fall back to linear search, but if we add an > entry via linear we would then overwrite the root index. We probably > want extra logic so that if we have a bad interior node we overwrite > that (or another leaf instead of killing the root index). We > probably also want to make a distinction between I/O errors and bad > data (currently I just return NULL for both). I think Al's idea of > doing the validation once on the initial read is a good one. I'm doing that in the current patch, for leaf blocks, look at ext2_bread. For index blocks, ext2_bread needs help to know that a block is supposed to be an index block. Add a parameter? The checks we're doing now aren't that expensive so I decided to take the lazy approach and just do them every time. It's not the same as the leaf block checks, which otherwise would need to be in the inner loop. [I'm still thinking about your comments on magic numbers and hash versions] > > - Finalize hash function > > I noticed something interesting when running "mongo" with debugging > on. It is adding filenames which are only sequential numbers, and the > hash code is basically adding to only two blocks until those blocks > are full, at which point (I guess) the blocks split and we add to two > other blocks. It's normal for it to start by putting all the entries into the first two blocks, but after those are split it should be pretty uniform across the resulting 4, and so on. Can you confirm it's unbalanced? I used to have a handy hash bucket-dumping function (dx_show_buckets) hooked into dir->read, which normally just returns an error. To get a dump you'd cat the directory. A hokey interface, for debugging only, but convenient for coding and using.This is gone from the page cache version and I should hook it back in somehow. > I will have to recompile and run with debugging on again to get > actual output. > > To me this would _seem_ bad, as it indicates the hash is not > uniformly distributing the files across the hash space. However, > skewed hashing may not necessarily be the bad for performance. It > may even be that because we never have to rebalance the hash index > structure that as long as we don't get large numbers of identical > hashes it is just fine if similar filenames produce similar hash > values. We just keep splitting the leaf blocks until the hash moves > over to a different "range". For a balanced tree-based structure a > skewed hash would be bad, because you would have to do full-tree > rebalancing very often then. > > > No known bugs, please test, thanks in advance. So much for that ;-) > Running mongo has shown up another bug, I see, but haven't had a > chance to look into yet. It involves not being able to delete files > from an indexed directory: > > rm: cannot remove `/mnt/tmp/testdir1-0-0/d0/d1/d2/d3/509.r': > Input/output error > > This is after the files had been renamed (.r suffix). Do we re-hash > directory entries if the file is renamed? If not, then that would > explain this problem. It _looks_ like we do the right thing, but the > mongo testing wipes out the filesystem after each test, and the above > message is from a logfile only. The rename creates the new entry via ext2_add_entry so the hash must be correct. Time to get out the bug swatter. I'll get mongo and try it. -- Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.4.5 crash on boot, SMP Alpha
Further variations on a theme. 2.4.4-ac15 works like a charm on these machines. -- Jay Thorne Manager, Systems & Technology, UserFriendly Media, Inc. ksymoops 2.4.0 on alpha 2.4.4-ac15. Options used -V (default) -K (specified) -L (specified) -o /lib/modules/2.4.5-ac5/ (specified) -m /usr/src/linux/System.map (specified) No modules in ksyms, skipping objects Unable to handle kernel paging request at virtual address 043ffc69c078 CPU 2 init(1): Oops 0 pc = [] ra = [] ps = Using defaults from ksymoops -t elf64-alpha -a alpha v0 = fc474238 t0 = 043ffc69bff8 t1 = 0007ff85 t2 = fc20 t3 = fc6a0150 t4 = 00040305 t5 = fc47fc80 t6 = t7 = fc000205c000 s0 = 00012008e068 s1 = fc47fcc8 s2 = fc47fc80 s3 = fc47bdc0 s4 = fc474238 s5 = f0f0f0f0f0f0f0f1 s6 = 000120006940 a0 = fc47fc80 a1 = fc47bdc0 a2 = fc474238 a3 = 0001 a4 = 00012008e068 a5 = t8 = t9 = t10= t11= pv = fc345bd0 at = gp = fc546300 sp = fc000205fad8 Code: a4830938 ldq t3,2360(t2) 40410522 subq t1,t0,t1 4841b682 srl t1,13,t1 48409721 sll t1,4,t0 40220401 addq t0,t1,t0 40240641 s8addq t0,t3,t0 a4820140 ldq t3,320(t1) Trace:fc3456ac fc345920 fc32aa38 fc31041c fc3100b0 fc310d68 fc336fd0 fc310d04 fc3100b0 fc3100b0 fc310684 fc310658 fc310684 Kernel panic: Attempted to kill init! Warning (Oops_read): Code line not seen, dumping what data is available >>PC; fc34550c<= Trace; fc3456ac Trace; fc345920 Trace; fc32aa38 Trace; fc31041c Trace; fc3100b0 Trace; fc310d68 Trace; fc336fd0 Trace; fc310d04 Trace; fc3100b0 Trace; fc3100b0 Trace; fc310684 Trace; fc310658 Trace; fc310684 1 warning issued. Results may not be reliable.
Re: [lkml]Re: [lkml]Re: interrupt problem with MPS 1.4 / not with MPS 1.1 ?
[EMAIL PROTECTED] wrote: > > 00:07.2 USB Controller: VIA Technologies, Inc. UHCI USB (rev 16) (prog-if 00 [UHCI]) > Subsystem: Unknown device 0925:1234 > Flags: bus master, medium devsel, latency 32, IRQ 5 > I/O ports at a000 [size=32] > Capabilities: [80] Power Management version 2 > 30: 00 00 00 00 80 00 00 00 00 00 00 00 05 04 00 00 > > 0x3X is at 5, not at 3. > You still run with MPS 1.1. It should be 3 or 19 after you reboot with MPS 1.4. Could you please try the following commands as root, but just before rebooting. It'll kill the USB controller. #setpci -s 00:07.2 INTERRUPT_LINE=15 #lspci -vx -s 00:07.2 <<< 0x3C should be 15 #setpci -s 00:07.2 INTERRUPT_LINE=19 #lspci -vx -s 00:07.2 <<< 0x3C is now either 19 or 3 -- Manfred - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Makefile patch for cscope and saner Ctags
Khachaturov, Vassilii <[EMAIL PROTECTED]> [01/05/31 15:00]: > Don't forget to bug RH package maintainer on that. Whatever bugzilla submitted > I use source-built cscope v.15.1, and -k works for me here, works for me too! > WHY?! Isn't it better to put $(shell cat cscope.files) on the list of I only have a yellow belt in makefile kungfu. These fancy gnu make things are relatively new to some of us... The latest patch is attached. include/linux/compile.h seems to get built whenever I run make, so that's why I've excluded it from the deps for cscope.out. --- Makefile.oldMon May 28 22:44:01 2001 +++ MakefileThu May 31 16:29:38 2001 @@ -334,10 +334,41 @@ # Exuberant ctags works better with -I tags: dummy - CTAGSF=`ctags --version | grep -i exuberant >/dev/null && echo "-I __initdata,__exitdata,EXPORT_SYMBOL,EXPORT_SYMBOL_NOVERS"`; \ + CTAGSF=`ctags --version | grep -i exuberant >/dev/null && echo "--sort=no -I +__initdata,__exitdata,EXPORT_SYMBOL,EXPORT_SYMBOL_NOVERS"`; \ ctags $$CTAGSF `find include/asm-$(ARCH) -name '*.h'` && \ - find include -type d \( -name "asm-*" -o -name config \) -prune -o -name '*.h' -print | xargs ctags $$CTAGSF -a && \ + find include -type f -name '*.h' -mindepth 2 -maxdepth 2 \ + | grep -v include/asm- | grep -v include/config \ + | xargs -r ctags $$CTAGSF -a && \ + find include -type f -name '*.h' -mindepth 3 -maxdepth 3 \ + | grep -v include/asm- | grep -v include/config \ + | xargs -r ctags $$CTAGSF -a && \ + find include -type f -name '*.h' -mindepth 4 -maxdepth 4 \ + | grep -v include/asm- | grep -v include/config \ + | xargs -r ctags $$CTAGSF -a && \ + find include -type f -name '*.h' -mindepth 5 -maxdepth 5 \ + | grep -v include/asm- | grep -v include/config \ + | xargs -r ctags $$CTAGSF -a && \ find $(SUBDIRS) init -name '*.c' | xargs ctags $$CTAGSF -a + mv tags tags.unsorted + LC_ALL=C sort -k 1,1 -s tags.unsorted > tags + rm tags.unsorted + +cscope.files: dummy + @find include/asm-$(ARCH) -name '*.h' >.cscope.files + @find include $(SUBDIRS) init -type f -name '*.[ch]' \ + | grep -v include/asm- | grep -v include/config >> .cscope.files + @[ -f cscope.files ] || touch cscope.files + @if cmp -s .cscope.files cscope.files ; then \ + /bin/rm .cscope.files ; \ + else \ + rm cscope.files ; mv .cscope.files cscope.files ; \ + fi + +.PHONY: cscope +cscope: cscope.out +cscope.out: cscope.files \ +$(shell [ -f cscope.files ] && grep -v include/linux/compile.h cscope.files) + cscope -k -b -I include ifdef CONFIG_MODULES ifdef CONFIG_MODVERSIONS @@ -416,7 +447,8 @@ distclean: mrproper rm -f core `find . \( -name '*.orig' -o -name '*.rej' -o -name '*~' \ -o -name '*.bak' -o -name '#*#' -o -name '.*.orig' \ - -o -name '.*.rej' -o -name '.SUMS' -o -size 0 \) -type f -print` TAGS tags + -o -name '.*.rej' -o -name '.SUMS' -o -size 0 \) -type f -print` TAGS +tags \ + cscope.files cscope.out backup: mrproper cd .. && tar cf - linux/ | gzip -9 > backup.gz
fork/open race results in wasted fd
Two tasks (A & B) share the same files_struct. A calls open() at the same time as B calls fork(). After A runs get_unused_fd() but before it calls fd_install(), B runs copy_files(). It looks like the result is one of the bits is set in B's open_fds field with no corresponding file pointer in its fd array. The fd is unusable, and attempting to close() it would return EBADF. Is this a known race? -Brian (please copy me in response) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Configure.help is complete
Arjan van de Ven <[EMAIL PROTECTED]>: > > Linux Kernel v2.4.5-ac5 Configuration > > CML1 > > > > Bottom of IDE, ATA and ATAPI Block devices; > > > > < > Support Promise software RAID (NEW) -> Help > > There is no help available for this kernel option. > > How about > "Say "Y" or "M" if you have a Promise Fasttrak (tm) Raid controller > and want linux to use the softwarraid feature of this card. > This driver uses /dev/ataraid/dXpY (X and Y numbers) as device names. > > If you have a Promise Fasttrak(tm) card but do not use the BIOS provided > raid feature, say "N". Um, tell me what the symbol name and prompt for this is, please? -- http://www.tuxedo.org/~esr/;>Eric S. Raymond [President Clinton] boasts about 186,000 people denied firearms under the Brady Law rules. The Brady Law has been in force for three years. In that time, they have prosecuted seven people and put three of them in prison. You know, the President has entertained more felons than that at fundraising coffees in the White House, for Pete's sake." -- Charlton Heston, FOX News Sunday, 18 May 1997 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Configure.help is complete
BH wrote: > > Great work, its nice to see none, or fewer No help availables in the kernel > configuration. > Some quick glances: > > Linux Kernel v2.4.5-ac5 Configuration > CML1 > > Bottom of IDE, ATA and ATAPI Block devices; > > < > Support Promise software RAID (NEW) -> Help > There is no help available for this kernel option. How about "Say "Y" or "M" if you have a Promise Fasttrak (tm) Raid controller and want linux to use the softwarraid feature of this card. This driver uses /dev/ataraid/dXpY (X and Y numbers) as device names. If you have a Promise Fasttrak(tm) card but do not use the BIOS provided raid feature, say "N". - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: no sound with CS4281 card
I'll send the latest driver that I have via separate email. Toshiba refuses to supply equipment, and there are some design issues with Toshiba laptops. I recently sent a driver to another Toshiba owner and he had good luck with the latest driver. I have never seen any Toshiba laptop not generate sound with any cs4281 driver at any time ( :) ), but that certainly doesn't rule out the 2.4.5-ac2 not working on a Toshiba 1755. I am pulling the 2.4.5-ac6 source now and will try on a 4281 ref card. mpg123 the only app not working? Thanks for the input tom -Original Message- From: Rik van Riel [mailto:[EMAIL PROTECTED]] Sent: Thursday, May 31, 2001 1:15 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject:no sound with CS4281 card Hi, my notebook (Toshiba 1755) comes with CS4281 built-in, with all 2.4 kernels I tried this sound card doesn't generate any sound, or interrupts for that matter. The driver detects the card fine, but doesn't seem to be able to do anything with it, on 2.4.5-ac2: /proc/pci Bus 0, device 8, function 0: Multimedia audio controller: Cirrus Logic Crystal CS4281 PCI Audio (rev 1). IRQ 5. Master Capable. Latency=64. Min Gnt=4.Max Lat=24. Non-prefetchable 32 bit memory at 0xfc01 [0xfc010fff]. Non-prefetchable 32 bit memory at 0xfc00 [0xfc00]. dmesg cs4281: version v1.13.32 time 15:54:07 May 29 2001 PCI: Enabling device 00:08.0 ( -> 0002) PCI: Found IRQ 5 for device 00:08.0 /proc/interrupts 5: 0 XT-PIC Crystal CS4281 (after trying to play music with mpg123 about 20 times) regards, Rik -- Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://distro.conectiva.com/ Send all your spam to [EMAIL PROTECTED] (spam digging piggy) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [lkml]Re: [lkml]Re: interrupt problem with MPS 1.4 / not with MPS 1.1 ?
On Thu, May 31, 2001 at 10:21:55PM +0200, Manfred Spraul wrote: > > > > I know that with MPS 1.4, the USB controller finds itself at an > > unshared interrupt 19. I can't reboot at the moment to check. > > > lspci -vxxx -s 00:07.0 > > the APIC sits in the southbridge. > the low 2 bits of offset 0x58 must be set [route USB IRQ to APIC], and > > lspci -vx -s 00:07.2 > > offset 0x3C must be set to 3 [19 & 15] > > There was some discussion about the same problem with the sound part of > the southbridge. > > What are the current values of these registers? > current, as in MPS 1.1: 00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] (rev 40) Subsystem: ABIT Computer Corp.: Unknown device Flags: bus master, stepping, medium devsel, latency 0 Capabilities: [c0] Power Management version 2 50: 02 76 04 00 00 f0 ab 50 1f 06 ff 08 00 00 00 00 I'd say the lower 2 bits at 0x58 are set. 00:07.2 USB Controller: VIA Technologies, Inc. UHCI USB (rev 16) (prog-if 00 [UHCI]) Subsystem: Unknown device 0925:1234 Flags: bus master, medium devsel, latency 32, IRQ 5 I/O ports at a000 [size=32] Capabilities: [80] Power Management version 2 30: 00 00 00 00 80 00 00 00 00 00 00 00 05 04 00 00 0x3X is at 5, not at 3. Greetings, Jurriaan -- Endora is where we are, and you need to know that describing this place is like dancing to no music. Peter Hedges - What's eating Gilbert Grape GNU/Linux 2.4.5-ac4 SMP/ReiserFS 2x1402 bogomips load av: 0.02 0.01 0.00 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [lkml]Re: interrupt problem with MPS 1.4 / not with MPS 1.1 ?
> > I know that with MPS 1.4, the USB controller finds itself at an > unshared interrupt 19. I can't reboot at the moment to check. > lspci -vxxx -s 00:07.0 the APIC sits in the southbridge. the low 2 bits of offset 0x58 must be set [route USB IRQ to APIC], and lspci -vx -s 00:07.2 offset 0x3C must be set to 3 [19 & 15] There was some discussion about the same problem with the sound part of the southbridge. What are the current values of these registers? -- Manfred - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Configure.help is complete
Great work, its nice to see none, or fewer No help availables in the kernel configuration. Some quick glances: Linux Kernel v2.4.5-ac5 Configuration CML1 Bottom of IDE, ATA and ATAPI Block devices; < > Support Promise software RAID (NEW) -> Help There is no help available for this kernel option. The Help for '[ ] IGNORE word93 Validation BITS' isn't much help either, although I safely say N and move on. Between SCSI and IEEE 1394; Fusion MPT device support ---> doesn't lead anywhere. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: union mounting file systems...
well... I just wondered how to (if possible) union mount two or more filesystems on a single mount point. The point that I want to bypass a bug/weakness in RedHat's installer is not really the case. I've tried to search the kernel mailing list archive, and find it's possible with mount -o union ... Problem is that I still can't see nothing but the last file system mounted on the mount point, so what is wrong? It may be an issue for other forums than lkml, but I really don't think RedHat is the place to go. Best regards roy On Thu, 31 May 2001, Vibol Hou wrote: > This sounds more like a RedHat issue than a LKML issue. Take it up with > RedHat. > > -- > Vibol Hou > KhmerConnection, http://khmer.cc > "Stay Connected." > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Roy Sigurd > Karlsbakk > Sent: Thursday, May 31, 2001 11:39 AM > To: [EMAIL PROTECTED] > Subject: union mounting file systems... > > > Hi all > > I just read the "Wonderful world of linux (2.4)", where it's said that the > Linux kernel 2.4 supports so-called union mounted file systems. I recently > downloaded the RedHat 7.1 distribution and loop-back mounted the CD's to > be able to install over ftp, but no... RedHat's install script reminds me > of all the flexibility you can get from an installer delivered from > Microsoft. After installing the stuff from CD #1, you're _not_ asked where > CD #2 is supposed to be; you just get loads of error messages on the > console. So - I can copy all the files from the two CD's - or - union > mount them (the .iso's) on a common directory. > > Does anyone know where I can find a mount program that actually does this? > > Please cc: to me, as I'm not on the list > > regards > > roy > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Configure.help is complete
On Thu, 31 May 2001, Arjan van de Ven wrote: > José Luis Domingo López wrote: > > > > On Thursday, 31 May 2001, at 13:24:54 -0400, > > Eric S. Raymond wrote: > > > > > It gives me great pleasure to announce that the Configure.help master > > > file is now complete with respect to 2.4.5. Every single one of the > > > 2699 configuration symbols actually used in the 2.4.5 codebase's C > > > source files or Makefiles now has an entry in Configure.help. > > > > > Would it be great to have a similar documentation for those hundreds of > > "files" under /proc ?. Something like: > > > Powertweak has descriptions for most of the usable /proc entries, > in XML format but the descriptions are easily extractable. Maybe it's > a good idea to make the powertweak set complete instead / share the set > with the kernel docs. We should start removing the crap from procfs in 2.5. Documenting shit is a good step, but taking it out would be better. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: interrupt problem with MPS 1.4 / not with MPS 1.1 ?
On Thu, May 31, 2001 at 09:48:35PM +0200, [EMAIL PROTECTED] wrote: > On Thu, May 31, 2001 at 11:06:42AM -0700, Greg KH wrote: > > On Thu, May 31, 2001 at 08:39:08PM +0200, [EMAIL PROTECTED] wrote: > > > What information would be necessary to debug this? > > > > Which kernel version? > > > > greg k-h > > > 2.4.5-ac4, but I rebooted in 2.4.4 and it did the same. Is the BIOS set to "Plug and Play supported OS" somewhere? If not, try enabling it. Also the MPS 1.4 boot messages would be helpful :) thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Configure.help is complete
José Luis Domingo López wrote: > > On Thursday, 31 May 2001, at 13:24:54 -0400, > Eric S. Raymond wrote: > > > It gives me great pleasure to announce that the Configure.help master > > file is now complete with respect to 2.4.5. Every single one of the > > 2699 configuration symbols actually used in the 2.4.5 codebase's C > > source files or Makefiles now has an entry in Configure.help. > > > Would it be great to have a similar documentation for those hundreds of > "files" under /proc ?. Something like: Powertweak has descriptions for most of the usable /proc entries, in XML format but the descriptions are easily extractable. Maybe it's a good idea to make the powertweak set complete instead / share the set with the kernel docs. Greetings, Arjan van de Ven - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [lkml]Re: interrupt problem with MPS 1.4 / not with MPS 1.1 ?
On Thu, May 31, 2001 at 11:06:42AM -0700, Greg KH wrote: > On Thu, May 31, 2001 at 08:39:08PM +0200, [EMAIL PROTECTED] wrote: > > What information would be necessary to debug this? > > Which kernel version? > > greg k-h > 2.4.5-ac4, but I rebooted in 2.4.4 and it did the same. I'll try and add some info here (from the bios= MPS 1.1 case!) I have the following expansion cards: Matrox G400 agp video-card ITI 4280 dual-UW scsi + fast ethernet card NCR860 ultra-scsi card Soundblaster Live! 5.1 card from dmesg: Total of 2 processors activated (2808.21 BogoMIPS). ENABLING IO-APIC IRQs ...changing IO-APIC physical APIC ID to 2 ... ok. init IO_APIC IRQs IO-APIC (apicid-pin) 2-0, 2-16, 2-17, 2-18, 2-19, 2-20, 2-21, 2-22, 2-23 not connected. ..TIMER: vector=49 pin1=2 pin2=0 number of MP IRQ sources: 16. number of IO-APIC #2 registers: 24. testing the IO APIC... IO APIC #2.. register #00: 0200 ...: physical APIC id: 02 register #01: 00178011 ... : max redirection entries: 0017 ... : IO APIC version: 0011 WARNING: unexpected IO-APIC, please mail to [EMAIL PROTECTED] register #02: ... : arbitration: 00 IRQ redirection table: NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect: 00 000 00 100 0 00000 01 003 03 000 0 01139 02 003 03 000 0 01131 03 003 03 000 0 01141 04 003 03 000 0 01149 05 003 03 110 1 01151 06 003 03 000 0 01159 07 003 03 000 0 01161 08 003 03 000 0 01169 09 003 03 000 0 01171 0a 003 03 110 1 01179 0b 003 03 110 1 01181 0c 003 03 000 0 01189 0d 003 03 000 0 01191 0e 003 03 000 0 01199 0f 003 03 110 1 011A1 10 000 00 100 0 00000 11 000 00 100 0 00000 12 000 00 100 0 00000 13 000 00 100 0 00000 14 000 00 100 0 00000 15 000 00 100 0 00000 16 000 00 100 0 00000 17 000 00 100 0 00000 IRQ to pin mappings: IRQ0 -> 0:2 IRQ1 -> 0:1 IRQ3 -> 0:3 IRQ4 -> 0:4 IRQ5 -> 0:5 IRQ6 -> 0:6 IRQ7 -> 0:7 IRQ8 -> 0:8 IRQ9 -> 0:9 IRQ10 -> 0:10 IRQ11 -> 0:11 IRQ12 -> 0:12 IRQ13 -> 0:13 IRQ14 -> 0:14 IRQ15 -> 0:15 done. Using local APIC timer interrupts. calibrating APIC timer ... . CPU clock speed is 703.1338 MHz. . host bus clock speed is 100.4475 MHz. cpu: 0, clocks: 1004475, slice: 334825 CPU0 cpu: 1, clocks: 1004475, slice: 334825 CPU1 checking TSC synchronization across CPUs: passed. mtrr: your CPUs had inconsistent variable MTRR settings mtrr: probably your BIOS does not setup all CPUs PCI: PCI BIOS revision 2.10 entry at 0xfb3a0, last bus=2 PCI: Using configuration type 1 PCI: Probing PCI hardware Unknown bridge resource 0: assuming transparent Unknown bridge resource 2: assuming transparent PCI: Using IRQ router VIA [1106/0686] at 00:07.0 Linux NET4.0 for Linux 2.4 usb.c: registered new driver hub uhci.c: USB UHCI at I/O 0xa000, IRQ 5 usb.c: new USB bus registered, assigned bus number 1 hub.c: USB hub found hub.c: 2 ports detected uhci.c: USB UHCI at I/O 0xa400, IRQ 5 usb.c: new USB bus registered, assigned bus number 2 hub.c: USB hub found hub.c: 2 ports detected uhci.c: Linus Torvalds, Johannes Erdfelt, Randy Dunlap, Georg Acher, Deti Fliegl, Thomas Sailer, Roman Weissgaerber uhci.c: USB Universal Host Controller Interface driver Initializing USB Mass Storage driver... usb.c: registered new driver usb-storage USB Mass Storage support registered. NET4: Linux TCP/IP 1.0 for NET4.0 Freeing unused kernel memory: 248k freed hub.c: USB new device connect on bus1/1, assigned device number 2 scsi3 : SCSI emulation for USB Mass Storage devices Vendor: IOMEGAModel: ZIP 250 Rev: 61.T Type: Direct-Access ANSI SCSI revision: 02 Attached scsi removable disk sda at scsi3, channel 0, id 0, lun 0 sda : READ CAPACITY failed. sda : status = 1, message = 00, host = 0, driver = 08 sda : extended sense code = 2 sda : block size assumed to be 512 bytes, disk size 1GB. sda: I/O error: dev 08:00, sector 0 unable to read partition table WARNING: USB Mass Storage data integrity not assured USB Mass Storage device found at 2 Adding Swap: 1047776k swap-space (priority -1) from lspci: 00:00.0 Host bridge: VIA Technologies, Inc. VT82C693A/694x [Apollo PRO133x] (rev c4) Subsystem: ABIT Computer Corp.: Unknown device a204 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Re: [Ext2-devel] [UPDATE] Directory index for ext2
Daniel, you write:
> - Fall back to linear search in case of corrupted index
OK, I have _some_ of the code needed to do this, but in one case I'm
not sure of what your intention was - in dx_probe() you check for
"unused_flags & 1" to signal a bad/unsupported index. Why only check
the low bit instead of the whole thing? I currently have:
if (dir->i_size < dir->i_sb->s_blocksize * 2)
goto fail; // bad EXT2_INDEX_FL set, clear?
if (IS_ERR(bh = ext2_bread (dir, 0, 0)))
goto fail; // FIXME error message?
root = (struct dx_root *) bh->b_data;
// use the following for production once hash_version is 1
// if (root->info.hash_version & 3 == 0 || root->info.unused_flags)
if (root->info.hash_version > 0 || root->info.unused_flags & 1)
goto fail2; // unsupported hash format
if ((indirect = root->info.indirect_levels) > 1)
goto fail2; // unsupported hash format
if (root->info.reserved_zero.v ||
root->info.info_length < sizeof(root->info))
goto fail2; // bad root node data
...
if (dx_get_limit(entries) != dx_root_limit(dir, root->info.info_length))
goto fail2; // bad root node data
...
if (dx_get_limit(entries) != dx_node_limit (dir))
goto fail3; // bad index node data
On lookup it is OK to fall back to linear search, but if we add an entry
via linear we would then overwrite the root index. We probably want extra
logic so that if we have a bad interior node we overwrite that (or another
leaf instead of killing the root index). We probably also want to make a
distinction between I/O errors and bad data (currently I just return NULL
for both). I think Al's idea of doing the validation once on the initial
read is a good one.
Instead of keeping reserved_zero as zero and using it to detect if an
inode number was written there, we could write a magic number there to
signal a valid hash. Alternately, instead of using hash_version to mark
the hash type, we could leave that unused and make the above magic
number the hash value, which is the hash of some fixed string, e.g.
HASH_V0 := dx_hack_hash("Daniel Phillips", 15) // constant value
HASH_V1 := dx_new_hash("Daniel Phillips", 15) // constant value
struct dx_root
{
struct fake_dirent dot;
char dot_name[4];
struct fake_dirent dotdot;
char dotdot_name[4];
struct dx_root_info {
le_u32 hash_magic;
u8 unused;
u8 info_length; /* 8 */
u8 indirect_levels;
u8 unused_flags;
} info;
struct dx_entry entries[0];
};
/*
* Hash value depends on existing hash type, so it is calculated here.
* For new directories we never use this function, and simply pick the
* default hash function when creating the new dx_root.
*/
static inline dx_frame *dx_probe(inode *dir, dentry *dentry, u32 *hash)
dx_frame *frame)
{
struct dx_root *root;
if (IS_ERR(bh = ext2_bread (dir, 0, 0)))
goto fail; // return error code
root = (struct dx_root *) bh->b_data;
switch (le32_to_cpu(root->info.hash_magic.v)) {
case HASH_V0:
// hash-specific dx_root validation here
*hash = dx_hack_hash(dentry->d_name.name, dentry->d_name.len);
return dx_probe_hash(dir, hash, frame, bh);
case HASH_V1:
// hash-specific dx_root validation here
*hash = dx_new_hash(dentry->d_name.name, dentry->d_name.len);
return dx_probe_hash(dir, hash, frame, bh);
default: printk("unsupported hash %u in directory %lu\n",
root->info.hash_magic, dir->i_ino);
brelse(bh);
*hash = 0;
}
fail:
return NULL;
}
> - Finalize hash function
I noticed something interesting when running "mongo" with debugging on.
It is adding filenames which are only sequential numbers, and the hash
code is basically adding to only two blocks until those blocks are full,
at which point (I guess) the blocks split and we add to two other blocks.
I haven't looked at it closely, but for _example_ it something like:
65531 to block 113
65532 to block 51
65533 to block 51
65534 to block 113
65535 to block 113
(repeats)
65600 to block 21
65601 to block 96
65602 to block 96
65603 to block 21
65604 to block 21
(repeats)
I will have to recompile and run with debugging on again to get actual
output.
To me this would _seem_ bad, as it indicates the hash is not uniformly
distributing the files across the hash space. However, skewed hashing
may not necessarily be the bad for performance. It may even be that
because we never have to rebalance the hash index structure that as long
as we don't get large
Re: [PATCH] net #6
Hi! > They are neccessary > > > @@ -643,9 +631,7 @@ > > eexp_hw_tx_pio(dev,data,length); > > } > > dev_kfree_skb(buf); > > -#ifdef CONFIG_SMP > > spin_unlock_irqrestore(>lock, flags); > > -#endif > > enable_irq(dev->irq); > > return 0; > > They are done this way to get good non SMP performance. Your changes would > ruin that. Maybe macro "spin_lock_irqsave_on_smp()" would be good idea? These ifdefs look ugly. Maybe local to driver, maybe even global. Pavel -- I'm [EMAIL PROTECTED] "In my country we have almost anarchy and I don't care." Panos Katsaloulis describing me w.r.t. patents at [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] reclaim dirty dead swapcache pages
Hi again, Vasco Figueira wrote: >I've opened x, gnome, mozilla, mozilla -mail, 3 gnome-terminals, pan, >xmms, some files and javac. Swap was totally filled up and it didn't >froze (good!). However suddently it came very busy (i thougth it was >going to freeze again), the music stopped, and came back to normal >again. It had killed xmms, I noticed after. >Is it intentional to kill processes? Well, it does reolve the problem, >but kills some processes, probably the most eager ones. I will keep >using this patch and report again if something relevant is found. >So far, so good, this is better tha having to swapoff & swapon all the >time. Nice work Marcelo. Continuing the saga of testing this patch, some more things: * Swap gets *really* filled up. I don't remember having swap totally filled with 2.2. and this has 20M more (doesn't have to do with this patch, I think) * kernel appears to try to free pages only when they are desperatly needed, i.e., when swap is full and a big process is needing mem. As an example, i was calm editing some text files (swap was full), and called javac. System went down to his knees, music stopped, mouse had repent stops and javac outputed:"Killed". I assume it was killed :-) javac was called again and then ran more smootly. Perhaps because his pages were already there, no? It may be better to try to free pages before we get into heavy load. If not, we get a pseudo-freeze and a killed process. Wich is not... wonderful. Comments? -- Regards, Vasco Figueira http://students.fct.unl.pt/users/vaf12086/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] simple_strtoull export
Missing kernel export for 'simple_strtoull' diff -u --recursive --new-file 2.4.5/kernel/ksyms.c 2.4.5.fixed/kernel/ksyms.c --- 2.4.5/kernel/ksyms.cWed May 30 10:13:14 2001 +++ 2.4.5.fixed/kernel/ksyms.cThu May 31 12:15:49 2001 @@ -461,6 +461,7 @@ EXPORT_SYMBOL(bdevname); EXPORT_SYMBOL(cdevname); EXPORT_SYMBOL(simple_strtoul); +EXPORT_SYMBOL(simple_strtoull); EXPORT_SYMBOL(system_utsname); /* UTS data */ EXPORT_SYMBOL(uts_sem);/* UTS semaphore */ #ifndef __mips__ -- Jason McMullan, Senior Linux Consultant Linuxcare, Inc. 412.432.6457 tel, 412.656.3519 cell [EMAIL PROTECTED], http://www.linuxcare.com/ Linuxcare. Putting open source to work. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: interrupt problem with MPS 1.4 / not with MPS 1.1 ?
On Thu, May 31, 2001 at 08:39:08PM +0200, [EMAIL PROTECTED] wrote: > What information would be necessary to debug this? Which kernel version? greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Scsi data parity errors on aix7xxx in kernel 2.4.5
Forgot to mention (in case it matters) that I'm running ReiserFS on sdd6 which is hanging off of scsi1. > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]] On Behalf Of Alok K. Dhir > Sent: Thursday, May 31, 2001 2:42 PM > To: [EMAIL PROTECTED] > Subject: Scsi data parity errors on aix7xxx in kernel 2.4.5 > > > > Running kernel 2.4.5 with two scsi controllers - scsi0 is a > sym53c8xx, scsi1 is aic7xxx. > > For the last month or so, I've been getting the following > error in my syslog 10 or so times a day: > > - > May 31 14:09:51 dog kernel: scsi1: PCI error Interrupt at > seqaddr = 0x8e May 31 14:09:51 dog kernel: scsi1: Data Parity > Error Detected during address or write data phase > - > > The box is a PIII-750 on an Aopen AX6BC (BX chipset) running > at 930Mhz (7.5 * 124Mhz bus speed), with 384 megs of RAM > (1*128MB PC100, 2*128MB PC133). I've tried running at > 7.5*100 and I still get the errors. > > Any advice as to what I should look at to solve this problem? > > Thanks > > - > To unsubscribe from this list: send the line "unsubscribe > linux-kernel" in the body of a message to > [EMAIL PROTECTED] More majordomo info at > http://vger.kernel.org/majordomo-info.html > Please read the > FAQ at http://www.tux.org/lkml/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Makefile patch for cscope and saner Ctags
> From: Mark Frazer [mailto:[EMAIL PROTECTED]] > Khachaturov, Vassilii <[EMAIL PROTECTED]> > > Great stuff. May I suggest adding -k to the cscope cmdline: > > + cscope -b -k -I include > > The cscope on my RH7.0 box didn't take -k! > [root@mjftest linux-2.4.5]# cscope -b -k -I include > cscope: unknown option: -k > [root@mjftest linux-2.4.5]# rpm -qf /usr/bin/cscope > cscope-13.0-6 > > weird, as man cscope documents -k's existence Don't forget to bug RH package maintainer on that. Whatever version they ship (I don't know, maybe 13 indeed didn't have -k) the mans and the binaries must be consistent. I use source-built cscope v.15.1, and -k works for me here, atop RH70 too. You can download it at http://cscope.sourceforge.net And, the cscope project guys are very responsive and willing to fix/implement things in their product. (BTW, anyone here knows how to submit a cvsweb patch/bug and get an answer? cvsweb at sourceforge seems dead, as well as cvsweb.org :-( ) You definitely want -k in the kernel Makefile to avoid irrelevant things from /usr/include!!! > I didn't see a way to add >>'ing the file to cscope.files > without greping > for it's entrance there already. So I've left the find ... method of > creating cscope.files. Sorry for being unclear. I meant: output the new find results into smth like .cscope.files, then compare (cmp -s) it to the current cscope.files, and replace the latter with it ONLY if there were diffs: > > The new .files should be created in a different file, and the old file > > shouldn't be replaced if there's no change. > cscope.out is now built by a shell command which does the checking > against the age of the files in cscope.files WHY?! Isn't it better to put $(shell cat cscope.files) on the list of cscope.out dependencies? Or, maybe better yet, cscope.make: cscope.files echo -n 'cscope.out: ' > .$@ cat $< >> .$@ mv .$@ $@ include cscope.make (or should it be `-include' here?) > Backout the old patch and try this one. [patch mostly snipped] > +.PHONY: scsope [patch mostly snipped] s/scs/csc/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Scsi data parity errors on aix7xxx in kernel 2.4.5
Running kernel 2.4.5 with two scsi controllers - scsi0 is a sym53c8xx, scsi1 is aic7xxx. For the last month or so, I've been getting the following error in my syslog 10 or so times a day: - May 31 14:09:51 dog kernel: scsi1: PCI error Interrupt at seqaddr = 0x8e May 31 14:09:51 dog kernel: scsi1: Data Parity Error Detected during address or write data phase - The box is a PIII-750 on an Aopen AX6BC (BX chipset) running at 930Mhz (7.5 * 124Mhz bus speed), with 384 megs of RAM (1*128MB PC100, 2*128MB PC133). I've tried running at 7.5*100 and I still get the errors. Any advice as to what I should look at to solve this problem? Thanks - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
interrupt problem with MPS 1.4 / not with MPS 1.1 ?
Hardware: Abit VP6 (Via 694x) x86/SMP motherboard with USB controller If I set the bios for MPS 1.1, USB runs fine. If I set the bios for MPS 1.4, I get this: May 31 13:08:06 middle kernel: hub.c: USB new device connect on bus1/1, assigned device number 4 May 31 13:08:09 middle kernel: usb_control/bulk_msg: timeout May 31 13:08:09 middle kernel: usb.c: USB device not accepting new address=4 (error=-110) May 31 13:08:09 middle kernel: hub.c: USB new device connect on bus1/1, assigned device number 5 May 31 13:08:12 middle kernel: usb_control/bulk_msg: timeout May 31 13:08:12 middle kernel: usb.c: USB device not accepting new address=5 (error=-110) May 31 13:08:12 middle kernel: hub.c: USB new device connect on bus1/1, assigned device number 6 May 31 13:08:15 middle kernel: usb_control/bulk_msg: timeout May 31 13:08:15 middle kernel: usb.c: USB device not accepting new address=6 (error=-110) May 31 13:08:16 middle kernel: hub.c: USB new device connect on bus1/1, assigned device number 7 May 31 13:08:19 middle kernel: usb_control/bulk_msg: timeout May 31 13:08:19 middle kernel: usb.c: USB device not accepting new address=7 (error=-110) May 31 13:08:19 middle kernel: hub.c: USB new device connect on bus1/1, assigned device number 8 May 31 13:08:22 middle kernel: usb_control/bulk_msg: timeout May 31 13:08:22 middle kernel: usb.c: USB device not accepting new address=8 (error=-110) May 31 13:08:22 middle kernel: hub.c: USB new device connect on bus1/1, assigned device number 9 Now I understand this mail doesn't have all the necessary info, but my question is: What information would be necessary to debug this? dmesg /var/log/messages lspci -vv (or -x?) or more? Jurriaan -- BOFH excuse #57: Groundskeepers stole the root password GNU/Linux 2.4.5-ac4 SMP/ReiserFS 2x1402 bogomips load av: 0.41 0.11 0.03 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
union mounting file systems...
Hi all I just read the "Wonderful world of linux (2.4)", where it's said that the Linux kernel 2.4 supports so-called union mounted file systems. I recently downloaded the RedHat 7.1 distribution and loop-back mounted the CD's to be able to install over ftp, but no... RedHat's install script reminds me of all the flexibility you can get from an installer delivered from Microsoft. After installing the stuff from CD #1, you're _not_ asked where CD #2 is supposed to be; you just get loads of error messages on the console. So - I can copy all the files from the two CD's - or - union mount them (the .iso's) on a common directory. Does anyone know where I can find a mount program that actually does this? Please cc: to me, as I'm not on the list regards roy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Emu10k1-devel] Re: how to crash 2.4.4 w/SBLive
On Thu, 31 May 2001, David Raufeisen wrote:
> Hi,
>
> I used this patch on 2.4.5, still oops's ..
But now it progressed a bit more ;)
>
> >>EIP; c01b91eb<=
> Trace; c01bc853
> Trace; c01b86c4
> Trace; c01b8666
> Trace; c01b4f4f
> Trace; c012cf46
> Trace; c0106bab
>
New patch attached.
>
> On Thursday, 31 May 2001, at 12:01:05 (+0200),
> [EMAIL PROTECTED] wrote:
>
> >
> > Thank you for the trace. Patch attached, please test it out.
> >
> > Rui Sousa
> >
> > P.S: in the future always CC emu10k1-devel, or instead of a 7 day delay in
> > getting something fixed the message might just get lost.
> >
diff -u -r1.166 audio.c
--- audio.c 2001/04/22 15:44:25 1.166
+++ audio.c 2001/05/31 17:23:03
@@ -1231,6 +1231,9 @@
woinst->buffer.ossfragshift = 0;
woinst->buffer.numfrags = 0;
woinst->device = (card->audio_dev1 == minor);
+ woinst->timer.state = TIMER_STATE_UNINSTALLED;
+ woinst->voice.usage = VOICE_USAGE_FREE;
+ woinst->buffer.emupageindex = -1;
init_waitqueue_head(>wait_queue);
Index: cardwo.c
===
RCS file: /usr/local/cvsroot/emu10k1/cardwo.c,v
retrieving revision 1.129
diff -u -r1.129 cardwo.c
--- cardwo.c2001/05/02 07:58:31 1.129
+++ cardwo.c2001/05/31 17:23:04
@@ -143,8 +143,10 @@
if (woinst->format.bitsperchannel == 16)
voice->flags |= VOICE_FLAGS_16BIT;
- if (emu10k1_voice_alloc(card, voice) < 0)
+ if (emu10k1_voice_alloc(card, voice) < 0) {
+ voice->usage = VOICE_USAGE_FREE;
return -1;
+ }
/* Calculate pitch */
voice->initial_pitch = (u16) (srToPitch(woinst->format.samplingrate) >> 8);
PROBLEM: isdn connecting error(auth failed) with 2.4.4-ac9 and 2.4.5
Hi! Here come the bugreport: 1: isdn connecting error(auth failed) with 2.4.4-ac9 and 2.4.5 2.: when trying to connect to my ISP with kernels 2.4.4-ac9 and 2.4.5 it always drops my connection with this(from syslog): May 27 15:00:50 kign kernel: ippp0: dialing 1 0651201201... May 27 15:00:51 kign kernel: isdn_net: ippp0 connected May 27 15:00:51 kign ipppd[391]: Local number: 2536889, Remote number: 0651201201, Type: outgoing May 27 15:00:51 kign ipppd[391]: PHASE_WAIT -> PHASE_ESTABLISHED, ifunit: 0, linkunit: 0, fd: 7 May 27 15:00:52 kign ipppd[391]: Remote message: Access Denied May 27 15:00:52 kign ipppd[391]: PAP authentication failed May 27 15:00:52 kign ipppd[391]: LCP terminated by peer May 27 15:00:52 kign kernel: ippp0: remote hangup May 27 15:00:52 kign kernel: ippp0: Chargesum is 0 May 27 15:00:52 kign kernel: ippp_ccp: freeing reset data structure c5f43800 May 27 15:00:52 kign kernel: ippp, open, slot: 0, minor: 1, state: May 27 15:00:52 kign kernel: ippp_ccp: allocated reset data structure c5f43800 May 27 15:00:52 kign ipppd[391]: Modem hangup May 27 15:00:52 kign ipppd[391]: Connection terminated. May 27 15:00:52 kign ipppd[391]: taking down PHASE_DEAD link 0, linkunit: 0 May 27 15:00:52 kign ipppd[391]: closing fd 7 from unit 0 May 27 15:00:52 kign ipppd[391]: link 0 closed , linkunit: 0 May 27 15:00:52 kign ipppd[391]: reinit_unit: 0 and my ISP do not know what is the problame, it works with the 2.4.4 kernel 3.: keywords: module,isdn, connectionerror 4.: 2.4.4-ac9 and 2.4.5 5.: -- 6.: -- 7.1: Compare to the current minimal requirements in Documentation/Changes. Linux kign 2.4.4 #3 Thu May 31 18:28:32 CEST 2001 i686 unknown Gnu C 2.95.2 Gnu make 3.79.1 binutils 2.9.5.0.37 util-linux util-linux Note: /usr/bin/fdformat is obsolete and is no longer available. util-linux Please use /usr/bin/superformat instead (make sure you have the util-linux fdutils package installed first). Also, there had been some util-linux major changes from version 4.x. Please refer to the documentation. util-linux mount 2.10f modutils 2.3.11 e2fsprogs 1.18 pcmcia-cs 3.1.8 PPP2.3.11 isdn4k-utils 3.1pre1 Linux C Library2.1.3 ldd: version 1.9.11 Procps 2.0.6 Net-tools 1.54 Console-tools 0.2.3 Sh-utils 2.0 Modules Loaded NVdriver hisax isdn slhc au8820 7.2: processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 8 model name : Pentium III (Coppermine) stepping: 6 cpu MHz : 834.554 cache size : 256 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 3 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 mmx fxsr sse bogomips: 1664.61 7.3: NVdriver 656144 15 hisax 158704 5 isdn 123472 6 [hisax] slhc4800 4 [isdn] au8820115976 1 7.4: 02:03.0 Network controller: Eicon Technology Corporation: Unknown device e005 (rev 01) Subsystem: Eicon Technology Corporation: Unknown device e005 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- http://phoemix.mayday.hu - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Configure.help is complete
> José Luis Domingo López <[EMAIL PROTECTED]>: > > Would it be great to have a similar documentation for those hundreds of > > "files" under /proc ?. > > Yes, this would be wonderful. Are you volunteering to write it? Some of it is documented - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] reclaim dirty dead swapcache pages
Hi, Marcelo Tosatti wrote: > I tested it and yes, it works. (...) > Please test. I've tested it against vanilla 2.4.5 and it resolves the freeze problem, though: I've opened x, gnome, mozilla, mozilla -mail, 3 gnome-terminals, pan, xmms, some files and javac. Swap was totally filled up and it didn't froze (good!). However suddently it came very busy (i thougth it was going to freeze again), the music stopped, and came back to normal again. It had killed xmms, I noticed after. Is it intentional to kill processes? Well, it does reolve the problem, but kills some processes, probably the most eager ones. I will keep using this patch and report again if something relevant is found. So far, so good, this is better tha having to swapoff & swapon all the time. Nice work Marcelo. -- Regards, Vasco Figueira http://students.fct.unl.pt/users/vaf12086/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Configure.help is complete
José Luis Domingo López <[EMAIL PROTECTED]>: > Would it be great to have a similar documentation for those hundreds of > "files" under /proc ?. Yes, this would be wonderful. Are you volunteering to write it? -- http://www.tuxedo.org/~esr/;>Eric S. Raymond [W]hat country can preserve its liberties, if its rulers are not warned from time to time that [the] people preserve the spirit of resistance? Let them take arms...The tree of liberty must be refreshed from time to time, with the blood of patriots and tyrants. -- Thomas Jefferson, letter to Col. William S. Smith, 1787 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Panic in initrd umount on 2.4.5 with analysis and fix
This is an interesting one, the panic is: Trying to unmount old root ... <1>Unable to handle kernel NULL pointer dereference at virtual address 0011 c018bf0d *pde = Oops: CPU:2 EIP:0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010202 eax: 0001 ebx: 1261 ecx: 0140 edx: c2135d70 esi: edi: ebp: f7d51f60 esp: c2135d50 ds: 0018 es: 0018 ss: 0018 Process swapper (pid: 1, stackpage=c2135000) Stack: c2134000 c013efba c2135d70 1261 0082 0900 f7d52800 0202 f8820a00 f75cd000 f7d546e0 f880664d f75cd000 0202 f75cd000 f8820a00 c0275a00 c2110100 c2118000 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Code: 8b 40 10 83 f8 02 7e 72 b8 f0 ff ff ff e9 88 00 00 00 90 b8 >>EIP; c018bf0d<= Trace; c013efba Trace; f8820a00 Trace; f880664d Trace; f8820a00 Trace; c011e810 Trace; c01123f1 Trace; c011e6ab Trace; c011e926 Trace; c011afa3 Trace; c01394f3 <__refile_buffer+63/70> Trace; c012d3ad Trace; c013b508 Trace; c012742d Trace; c014bf20 Trace; c014d7e2 Trace; c013f25d Trace; c013cf9f Trace; c0105000 Trace; c011a096 Trace; c0105000 Trace; c01051cc Trace; c010521d Trace; c0105000 Trace; c0105606 Trace; c01051f0 Code; c018bf0d <_EIP>: Code; c018bf0d<= 0: 8b 40 10 mov0x10(%eax),%eax <= Code; c018bf10 3: 83 f8 02 cmp$0x2,%eax Code; c018bf13 6: 7e 72 jle7a <_EIP+0x7a> c018bf87 Code; c018bf15 8: b8 f0 ff ff ffmov$0xfff0,%eax Code; c018bf1a d: e9 88 00 00 00jmp9a <_EIP+0x9a> c018bfa7 Code; c018bf1f 12: 90nop Code; c018bf20 13: b8 00 00 00 00mov$0x0,%eax The panic is caused by rd.c: if (inode->i_bdev && (atomic_read(>i_bdev->bd_openers) > 2)) return -EBUSY; destroy_buffers(inode->i_rdev); with inode-i_bdev set to 1. This seems to be caused because the ioctl_by_bdev() call uses a fake inode which has only i_rdev populated. The 1 is coming because the struct inode is not explicitly cleared so it's picking up random crud from the stack. The fix is either to explicitly clear the fake inode and check for a null in rd_ioctl or to populate the i_bdev field from the bdev passed into ioctl_by_bdev(). I fixed it the former way and it works fine for me. The odd thing is that this code is unchanged between 2.4.4 (which works fine) and 2.4.5 and I have a hard time believing that everybody's initrd works OK purely because the stack crud populating i_bdev in the fake inode happens to be dereferenceable. James Bottomley - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Makefile patch for cscope and saner Ctags
Pete Wyckoff <[EMAIL PROTECTED]> [01/05/31 13:56]:
>
> You seem not to have read my response to your earlier mail proprosing
> such a thing (for tags only, not cscope):
>
> http://boudicca.tux.org/hypermail/linux-kernel/2001week21/1869.html
I did. I didn't want to sign up to maintain the ctags-ignore file though.
>
> How does the patch above fix anything? You're sorting so that
> include/linux/*.h comes before include/linux/{mtd,lockd,raid,...}/*.h,
> but I don't see how that can be an improvement, or how it addresses
> your original complaint "ctags doesn't honour any CPP #if'ing".
The sort -s is a stable sort, so by putting things into ctags in the
order I want them to appear in my tags file I get what I want. YMMV
My original complaint ain't gonna get fixed anytime soon.
Your script is definitely a better solution IMO.
-mark
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
no sound with CS4281 card
Hi, my notebook (Toshiba 1755) comes with CS4281 built-in, with all 2.4 kernels I tried this sound card doesn't generate any sound, or interrupts for that matter. The driver detects the card fine, but doesn't seem to be able to do anything with it, on 2.4.5-ac2: /proc/pci Bus 0, device 8, function 0: Multimedia audio controller: Cirrus Logic Crystal CS4281 PCI Audio (rev 1). IRQ 5. Master Capable. Latency=64. Min Gnt=4.Max Lat=24. Non-prefetchable 32 bit memory at 0xfc01 [0xfc010fff]. Non-prefetchable 32 bit memory at 0xfc00 [0xfc00]. dmesg cs4281: version v1.13.32 time 15:54:07 May 29 2001 PCI: Enabling device 00:08.0 ( -> 0002) PCI: Found IRQ 5 for device 00:08.0 /proc/interrupts 5: 0 XT-PIC Crystal CS4281 (after trying to play music with mpg123 about 20 times) regards, Rik -- Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://distro.conectiva.com/ Send all your spam to [EMAIL PROTECTED] (spam digging piggy) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
