* [PATCH] PCI hotplug changes for 2.5.54
From: Greg KH @ 2003-01-08 1:55 UTC (permalink / raw)
To: linux-kernel, pcihpd-discuss
In-Reply-To: <20030108015500.GA30924@kroah.com>
ChangeSet 1.894, 2003/01/07 16:24:14-08:00, greg@kroah.com
IBM PCI Hotplug: fix compile time error due to find_bus() function name.
diff -Nru a/drivers/hotplug/ibmphp_core.c b/drivers/hotplug/ibmphp_core.c
--- a/drivers/hotplug/ibmphp_core.c Tue Jan 7 16:45:11 2003
+++ b/drivers/hotplug/ibmphp_core.c Tue Jan 7 16:45:11 2003
@@ -769,11 +769,11 @@
* Parameters: bus number
* Returns : pci_bus * or NULL if not found
*/
-static struct pci_bus *find_bus (u8 busno)
+static struct pci_bus *ibmphp_find_bus (u8 busno)
{
const struct list_head *tmp;
struct pci_bus *bus;
- debug ("inside find_bus, busno = %x \n", busno);
+ debug ("inside %s, busno = %x \n", __FUNCTION__, busno);
list_for_each (tmp, &pci_root_buses) {
bus = (struct pci_bus *) pci_bus_b (tmp);
@@ -1002,7 +1002,7 @@
struct pci_dev *dev;
u16 l;
- if (find_bus (busno) || !(ibmphp_find_same_bus_num (busno)))
+ if (ibmphp_find_bus (busno) || !(ibmphp_find_same_bus_num (busno)))
return 1;
bus = kmalloc (sizeof (*bus), GFP_KERNEL);
@@ -1056,7 +1056,7 @@
func->dev = pci_find_slot (func->busno, (func->device << 3) | (func->function & 0x7));
if (func->dev == NULL) {
- dev0.bus = find_bus (func->busno);
+ dev0.bus = ibmphp_find_bus (func->busno);
dev0.devfn = ((func->device << 3) + (func->function & 0x7));
dev0.sysdata = dev0.bus->sysdata;
@@ -1636,7 +1636,7 @@
return -ENOMEM;
}
- bus = find_bus (0);
+ bus = ibmphp_find_bus (0);
if (!bus) {
err ("Can't find the root pci bus, can not continue\n");
return -ENODEV;
^ permalink raw reply
* [BK PATCH] PCI hotplug changes for 2.5.54
From: Greg KH @ 2003-01-08 1:55 UTC (permalink / raw)
To: torvalds; +Cc: linux-kernel, pcihpd-discuss
Here are some minor PCI hotplug changes for 2.5.54.
Please pull from: bk://linuxusb.bkbits.net/pci_hp-2.5
thanks,
greg k-h
drivers/hotplug/ibmphp_core.c | 10 ++++-----
drivers/hotplug/pci_hotplug_core.c | 41 ++++++++++++++++++-------------------
drivers/pci/hotplug.c | 2 -
3 files changed, 26 insertions(+), 27 deletions(-)
-----
ChangeSet@1.896, 2003-01-07 16:41:22-08:00, greg@kroah.com
PCI hotplug: clean up the try_module_get() logic a bit.
drivers/hotplug/pci_hotplug_core.c | 41 ++++++++++++++++++-------------------
1 files changed, 20 insertions(+), 21 deletions(-)
------
ChangeSet@1.895, 2003-01-07 16:29:23-08:00, greg@kroah.com
PCI: properly unregister a PCI device if it is removed.
This is only used by pci hotplug and cardbus systems.
drivers/pci/hotplug.c | 2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
------
ChangeSet@1.894, 2003-01-07 16:24:14-08:00, greg@kroah.com
IBM PCI Hotplug: fix compile time error due to find_bus() function name.
drivers/hotplug/ibmphp_core.c | 10 +++++-----
1 files changed, 5 insertions(+), 5 deletions(-)
------
^ permalink raw reply
* Re: [2.5.54-dj1-bk] Some interesting experiences...
From: Anders Gustafsson @ 2003-01-08 1:51 UTC (permalink / raw)
To: Joshua Kwan; +Cc: linux-kernel, vojtech
In-Reply-To: <20030107172147.3c53efa8.joshk@ludicrus.ath.cx>
On Tue, Jan 07, 2003 at 05:21:46PM -0800, Joshua Kwan wrote:
>
> 3. [linux-2.5] PS/2 mouse goes haywire every 30 seconds or so of use.
> dmesg sayeth:
> mice: PS/2 mouse device common for all mice
> input: PS/2 Synaptics TouchPad on isa0060/serio4
>
> but more importantly this is the cause:
>
> psmouse.c: Lost synchronization, throwing 2 bytes away.
> psmouse.c: Lost synchronization, throwing 2 bytes away.
This happens here too. But not that frequent at all, more like once every
hour. And has happend on all kernels since at least 2.5.46 [1].
However 5 hours ago I changed the timeout in psmouse.c from 50ms to 100ms.
And now it haven't misbehaved yet, but that might be just some nightly luck.
Is there something that turns off interupts or something and hinders the
mouse driver from processing the data for such long time? Or is my hardware
just buggy?
[1] http://marc.theaimsgroup.com/?l=linux-kernel&m=103688231622278&w=2
--
Anders Gustafsson - andersg@0x63.nu - http://0x63.nu/
^ permalink raw reply
* how to filter tagged frames of different vlanid in one bridge?
From: zhengchuanbo @ 2003-01-08 1:41 UTC (permalink / raw)
To: netfilter-devel
we use linux as our firewall. the firewall worked at bridge mode. it is connected to the trunk port of the switch. what we want to do is to filter the vlan tagged frames(802.1Q) by ip address.i tried two methods:
1.by ebtables
ebtables can filter 802.1Q protocol. but it can not filter by ip address. it can only filter the ip address when the protocol is IPV4. i wish i could do the job by ebtables.
2.by bridge-nf patch and vconfig
i can filter by ip address to certain tagged frames. i did it like this,
/sbin/vconfig add eth0 2
/sbin/vconfig add eth1 2
ifconfig eth0.2 up
ifconfig eth1.2 up
brctl addbr br0
brctl addif eth0.2
brctl addif eth1.2
after i applied the patch bridge-nf,netfilter works for the vlan frames. the problem is we have many vlans(more than ten). so i have to build a bridge for all the vlans.
so what i want to do is to filter the tagged frames of differen vlans in the same bridge. i can't find a way to do that. is there some solution to that?
thanks in advance. please cc.
regards,
chuanbo zheng
zhengcb@netpower.com.cn
^ permalink raw reply
* Re: [linux-audio-user] Re: alsaplayer not working with alsa?
From: Mark Knecht @ 2003-01-08 1:37 UTC (permalink / raw)
To: Takashi Iwai; +Cc: Alsa-List, Alsa-Devel
In-Reply-To: <s5hptr99cjg.wl@alsa2.suse.de>
[-- Attachment #1: Type: text/plain, Size: 1511 bytes --]
Takashi-san,
I am attaching my current asound.state file. The installed card is an
RME HDSP 9652, their new card. My current modules.conf looks like:
alias parport_lowlevel parport_pc
alias eth0 eepro100
alias usb-controller usb-uhci
# --- BEGIN: Generated by ALSACONF, do not edit. ---
# --- ALSACONF verion 0.9.0 ---
alias char-major-116 snd
alias snd-card-0 snd-hdsp
alias char-major-14 soundcore
alias sound-slot-0 snd-card-0
alias sound-service-0-0 snd-mixer-oss
alias sound-service-0-1 snd-seq-oss
alias sound-service-0-3 snd-pcm-oss
alias sound-service-0-8 snd-seq-oss
alias sound-service-0-12 snd-pcm-oss
options snd major=116 cards_limit=3 device_mode=0666
options snd-hdsp index=0
options snd-usb-audio index=1
# --- END: Generated by ALSACONF, do not edit. ---
# -- Keep modules from being autocleaned
add options -k snd-card-0
add options -k snd-card-1
The alsaplayer failure when jack is not running looks like:
[mark@Godzilla mark]$ alsaplayer
alsaplayer: pcm.c:6293: snd_pcm_unlink_ptr: Assertion `0' failed.
AlsaPlayer interrupted by signal 6
[mark@Godzilla mark]$
Please let me know if thee is more information you'd like to look at.
Thanks,
Mark
On Tue, 2003-01-07 at 07:58, Takashi Iwai wrote:
> At 27 Dec 2002 14:56:22 -0800,
> Mark Knecht wrote:
> >
> > No, just standard Intel hardware...
>
> well, then you have an exotic one :)
>
> could you show /etc/asound.state?
> perhaps the card lacks of some mixer controls which are required.
>
>
> thanks,
>
> Takashi
[-- Attachment #2: asound.state --]
[-- Type: text/plain, Size: 27946 bytes --]
state.DSP {
control.1 {
comment.access 'read write'
comment.type IEC958
iface PCM
name 'IEC958 Playback Default'
value '0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000'
}
control.2 {
comment.access 'read write inactive'
comment.type IEC958
iface PCM
name 'IEC958 Playback PCM Stream'
value '0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000'
}
control.3 {
comment.access read
comment.type IEC958
iface MIXER
name 'IEC958 Playback Con Mask'
value '3b00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000'
}
control.4 {
comment.access read
comment.type IEC958
iface MIXER
name 'IEC958 Playback Pro Mask'
value '1f00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000'
}
control.5 {
comment.access 'read write'
comment.type INTEGER
comment.range '0 - 65536 (step 1)'
iface PCM
name Mixer
value.0 0
value.1 0
value.2 0
}
control.6 {
comment.access 'read write'
comment.type ENUMERATED
comment.item.0 ADAT1
comment.item.1 Coaxial
comment.item.2 Internal
iface PCM
name 'IEC958 Input Connector'
value Internal
}
control.7 {
comment.access 'read write'
comment.type BOOLEAN
iface PCM
name 'IEC958 Output also on ADAT1'
value false
}
control.8 {
comment.access 'read write'
comment.type ENUMERATED
comment.item.0 Internal
comment.item.1 Word
comment.item.2 'ADAT Sync'
comment.item.3 IEC958
comment.item.4 ADAT1
comment.item.5 ADAT2
comment.item.6 ADAT3
iface PCM
name 'Preferred Sync Source'
value Internal
}
control.9 {
comment.access 'read write'
comment.type BOOLEAN
iface PCM
name Passthru
value false
}
control.10 {
comment.access 'read write'
comment.type BOOLEAN
iface PCM
name 'Line Out'
value true
}
control.11 {
comment.access 'read write'
comment.type INTEGER
comment.range '0 - 65536 (step 1)'
iface MIXER
name Chn
index 1
value 15732
}
control.12 {
comment.access read
comment.type INTEGER
comment.range '0 - 0'
iface PCM
name 'Input Peak'
index 1
value.0 0
value.1 0
}
control.13 {
comment.access read
comment.type INTEGER
comment.range '0 - 0'
iface PCM
name 'Output Peak'
index 1
value.0 0
value.1 0
}
control.14 {
comment.access read
comment.type INTEGER
comment.range '0 - 0'
iface PCM
name 'Playback Peak'
index 1
value.0 0
value.1 0
}
control.15 {
comment.access read
comment.type INTEGER64
comment.range '0 - 0'
iface PCM
name 'Playback RMS'
index 1
value 0
}
control.16 {
comment.access read
comment.type INTEGER64
comment.range '0 - 0'
iface PCM
name 'Input RMS'
index 1
value 0
}
control.17 {
comment.access 'read write'
comment.type INTEGER
comment.range '0 - 65536 (step 1)'
iface MIXER
name Chn
index 2
value 15732
}
control.18 {
comment.access read
comment.type INTEGER
comment.range '0 - 0'
iface PCM
name 'Input Peak'
index 2
value.0 0
value.1 0
}
control.19 {
comment.access read
comment.type INTEGER
comment.range '0 - 0'
iface PCM
name 'Output Peak'
index 2
value.0 0
value.1 0
}
control.20 {
comment.access read
comment.type INTEGER
comment.range '0 - 0'
iface PCM
name 'Playback Peak'
index 2
value.0 0
value.1 0
}
control.21 {
comment.access read
comment.type INTEGER64
comment.range '0 - 0'
iface PCM
name 'Playback RMS'
index 2
value 0
}
control.22 {
comment.access read
comment.type INTEGER64
comment.range '0 - 0'
iface PCM
name 'Input RMS'
index 2
value 0
}
control.23 {
comment.access 'read write'
comment.type INTEGER
comment.range '0 - 65536 (step 1)'
iface MIXER
name Chn
index 3
value 15732
}
control.24 {
comment.access read
comment.type INTEGER
comment.range '0 - 0'
iface PCM
name 'Input Peak'
index 3
value.0 0
value.1 0
}
control.25 {
comment.access read
comment.type INTEGER
comment.range '0 - 0'
iface PCM
name 'Output Peak'
index 3
value.0 0
value.1 0
}
control.26 {
comment.access read
comment.type INTEGER
comment.range '0 - 0'
iface PCM
name 'Playback Peak'
index 3
value.0 0
value.1 0
}
control.27 {
comment.access read
comment.type INTEGER64
comment.range '0 - 0'
iface PCM
name 'Playback RMS'
index 3
value 0
}
control.28 {
comment.access read
comment.type INTEGER64
comment.range '0 - 0'
iface PCM
name 'Input RMS'
index 3
value 0
}
control.29 {
comment.access 'read write'
comment.type INTEGER
comment.range '0 - 65536 (step 1)'
iface MIXER
name Chn
index 4
value 15732
}
control.30 {
comment.access read
comment.type INTEGER
comment.range '0 - 0'
iface PCM
name 'Input Peak'
index 4
value.0 0
value.1 0
}
control.31 {
comment.access read
comment.type INTEGER
comment.range '0 - 0'
iface PCM
name 'Output Peak'
index 4
value.0 0
value.1 0
}
control.32 {
comment.access read
comment.type INTEGER
comment.range '0 - 0'
iface PCM
name 'Playback Peak'
index 4
value.0 0
value.1 0
}
control.33 {
comment.access read
comment.type INTEGER64
comment.range '0 - 0'
iface PCM
name 'Playback RMS'
index 4
value 0
}
control.34 {
comment.access read
comment.type INTEGER64
comment.range '0 - 0'
iface PCM
name 'Input RMS'
index 4
value 0
}
control.35 {
comment.access 'read write'
comment.type INTEGER
comment.range '0 - 65536 (step 1)'
iface MIXER
name Chn
index 5
value 15732
}
control.36 {
comment.access read
comment.type INTEGER
comment.range '0 - 0'
iface PCM
name 'Input Peak'
index 5
value.0 0
value.1 0
}
control.37 {
comment.access read
comment.type INTEGER
comment.range '0 - 0'
iface PCM
name 'Output Peak'
index 5
value.0 0
value.1 0
}
control.38 {
comment.access read
comment.type INTEGER
comment.range '0 - 0'
iface PCM
name 'Playback Peak'
index 5
value.0 0
value.1 0
}
control.39 {
comment.access read
comment.type INTEGER64
comment.range '0 - 0'
iface PCM
name 'Playback RMS'
index 5
value 0
}
control.40 {
comment.access read
comment.type INTEGER64
comment.range '0 - 0'
iface PCM
name 'Input RMS'
index 5
value 0
}
control.41 {
comment.access 'read write'
comment.type INTEGER
comment.range '0 - 65536 (step 1)'
iface MIXER
name Chn
index 6
value 17043
}
control.42 {
comment.access read
comment.type INTEGER
comment.range '0 - 0'
iface PCM
name 'Input Peak'
index 6
value.0 0
value.1 0
}
control.43 {
comment.access read
comment.type INTEGER
comment.range '0 - 0'
iface PCM
name 'Output Peak'
index 6
value.0 0
value.1 0
}
control.44 {
comment.access read
comment.type INTEGER
comment.range '0 - 0'
iface PCM
name 'Playback Peak'
index 6
value.0 0
value.1 0
}
control.45 {
comment.access read
comment.type INTEGER64
comment.range '0 - 0'
iface PCM
name 'Playback RMS'
index 6
value 0
}
control.46 {
comment.access read
comment.type INTEGER64
comment.range '0 - 0'
iface PCM
name 'Input RMS'
index 6
value 0
}
control.47 {
comment.access 'read write'
comment.type INTEGER
comment.range '0 - 65536 (step 1)'
iface MIXER
name Chn
index 7
value 17043
}
control.48 {
comment.access read
comment.type INTEGER
comment.range '0 - 0'
iface PCM
name 'Input Peak'
index 7
value.0 0
value.1 0
}
control.49 {
comment.access read
comment.type INTEGER
comment.range '0 - 0'
iface PCM
name 'Output Peak'
index 7
value.0 0
value.1 0
}
control.50 {
comment.access read
comment.type INTEGER
comment.range '0 - 0'
iface PCM
name 'Playback Peak'
index 7
value.0 0
value.1 0
}
control.51 {
comment.access read
comment.type INTEGER64
comment.range '0 - 0'
iface PCM
name 'Playback RMS'
index 7
value 0
}
control.52 {
comment.access read
comment.type INTEGER64
comment.range '0 - 0'
iface PCM
name 'Input RMS'
index 7
value 0
}
control.53 {
comment.access 'read write'
comment.type INTEGER
comment.range '0 - 65536 (step 1)'
iface MIXER
name Chn
index 8
value 17043
}
control.54 {
comment.access read
comment.type INTEGER
comment.range '0 - 0'
iface PCM
name 'Input Peak'
index 8
value.0 0
value.1 0
}
control.55 {
comment.access read
comment.type INTEGER
comment.range '0 - 0'
iface PCM
name 'Output Peak'
index 8
value.0 0
value.1 0
}
control.56 {
comment.access read
comment.type INTEGER
comment.range '0 - 0'
iface PCM
name 'Playback Peak'
index 8
value.0 0
value.1 0
}
control.57 {
comment.access read
comment.type INTEGER64
comment.range '0 - 0'
iface PCM
name 'Playback RMS'
index 8
value 0
}
control.58 {
comment.access read
comment.type INTEGER64
comment.range '0 - 0'
iface PCM
name 'Input RMS'
index 8
value 0
}
control.59 {
comment.access 'read write'
comment.type INTEGER
comment.range '0 - 65536 (step 1)'
iface MIXER
name Chn
index 9
value 17043
}
control.60 {
comment.access read
comment.type INTEGER
comment.range '0 - 0'
iface PCM
name 'Input Peak'
index 9
value.0 0
value.1 0
}
control.61 {
comment.access read
comment.type INTEGER
comment.range '0 - 0'
iface PCM
name 'Output Peak'
index 9
value.0 0
value.1 0
}
control.62 {
comment.access read
comment.type INTEGER
comment.range '0 - 0'
iface PCM
name 'Playback Peak'
index 9
value.0 0
value.1 0
}
control.63 {
comment.access read
comment.type INTEGER64
comment.range '0 - 0'
iface PCM
name 'Playback RMS'
index 9
value 0
}
control.64 {
comment.access read
comment.type INTEGER64
comment.range '0 - 0'
iface PCM
name 'Input RMS'
index 9
value 0
}
control.65 {
comment.access 'read write'
comment.type INTEGER
comment.range '0 - 65536 (step 1)'
iface MIXER
name Chn
index 10
value 19665
}
control.66 {
comment.access read
comment.type INTEGER
comment.range '0 - 0'
iface PCM
name 'Input Peak'
index 10
value.0 0
value.1 0
}
control.67 {
comment.access read
comment.type INTEGER
comment.range '0 - 0'
iface PCM
name 'Output Peak'
index 10
value.0 0
value.1 0
}
control.68 {
comment.access read
comment.type INTEGER
comment.range '0 - 0'
iface PCM
name 'Playback Peak'
index 10
value.0 0
value.1 0
}
control.69 {
comment.access read
comment.type INTEGER64
comment.range '0 - 0'
iface PCM
name 'Playback RMS'
index 10
value 0
}
control.70 {
comment.access read
comment.type INTEGER64
comment.range '0 - 0'
iface PCM
name 'Input RMS'
index 10
value 0
}
control.71 {
comment.access 'read write'
comment.type INTEGER
comment.range '0 - 65536 (step 1)'
iface MIXER
name Chn
index 11
value 0
}
control.72 {
comment.access read
comment.type INTEGER
comment.range '0 - 0'
iface PCM
name 'Input Peak'
index 11
value.0 0
value.1 0
}
control.73 {
comment.access read
comment.type INTEGER
comment.range '0 - 0'
iface PCM
name 'Output Peak'
index 11
value.0 0
value.1 0
}
control.74 {
comment.access read
comment.type INTEGER
comment.range '0 - 0'
iface PCM
name 'Playback Peak'
index 11
value.0 0
value.1 0
}
control.75 {
comment.access read
comment.type INTEGER64
comment.range '0 - 0'
iface PCM
name 'Playback RMS'
index 11
value 0
}
control.76 {
comment.access read
comment.type INTEGER64
comment.range '0 - 0'
iface PCM
name 'Input RMS'
index 11
value 0
}
control.77 {
comment.access 'read write'
comment.type INTEGER
comment.range '0 - 65536 (step 1)'
iface MIXER
name Chn
index 12
value 0
}
control.78 {
comment.access read
comment.type INTEGER
comment.range '0 - 0'
iface PCM
name 'Input Peak'
index 12
value.0 0
value.1 0
}
control.79 {
comment.access read
comment.type INTEGER
comment.range '0 - 0'
iface PCM
name 'Output Peak'
index 12
value.0 0
value.1 0
}
control.80 {
comment.access read
comment.type INTEGER
comment.range '0 - 0'
iface PCM
name 'Playback Peak'
index 12
value.0 0
value.1 0
}
control.81 {
comment.access read
comment.type INTEGER64
comment.range '0 - 0'
iface PCM
name 'Playback RMS'
index 12
value 0
}
control.82 {
comment.access read
comment.type INTEGER64
comment.range '0 - 0'
iface PCM
name 'Input RMS'
index 12
value 0
}
control.83 {
comment.access 'read write'
comment.type INTEGER
comment.range '0 - 65536 (step 1)'
iface MIXER
name Chn
index 13
value 0
}
control.84 {
comment.access read
comment.type INTEGER
comment.range '0 - 0'
iface PCM
name 'Input Peak'
index 13
value.0 0
value.1 0
}
control.85 {
comment.access read
comment.type INTEGER
comment.range '0 - 0'
iface PCM
name 'Output Peak'
index 13
value.0 0
value.1 0
}
control.86 {
comment.access read
comment.type INTEGER
comment.range '0 - 0'
iface PCM
name 'Playback Peak'
index 13
value.0 0
value.1 0
}
control.87 {
comment.access read
comment.type INTEGER64
comment.range '0 - 0'
iface PCM
name 'Playback RMS'
index 13
value 0
}
control.88 {
comment.access read
comment.type INTEGER64
comment.range '0 - 0'
iface PCM
name 'Input RMS'
index 13
value 0
}
control.89 {
comment.access 'read write'
comment.type INTEGER
comment.range '0 - 65536 (step 1)'
iface MIXER
name Chn
index 14
value 0
}
control.90 {
comment.access read
comment.type INTEGER
comment.range '0 - 0'
iface PCM
name 'Input Peak'
index 14
value.0 0
value.1 0
}
control.91 {
comment.access read
comment.type INTEGER
comment.range '0 - 0'
iface PCM
name 'Output Peak'
index 14
value.0 0
value.1 0
}
control.92 {
comment.access read
comment.type INTEGER
comment.range '0 - 0'
iface PCM
name 'Playback Peak'
index 14
value.0 0
value.1 0
}
control.93 {
comment.access read
comment.type INTEGER64
comment.range '0 - 0'
iface PCM
name 'Playback RMS'
index 14
value 0
}
control.94 {
comment.access read
comment.type INTEGER64
comment.range '0 - 0'
iface PCM
name 'Input RMS'
index 14
value 0
}
control.95 {
comment.access 'read write'
comment.type INTEGER
comment.range '0 - 65536 (step 1)'
iface MIXER
name Chn
index 15
value 0
}
control.96 {
comment.access read
comment.type INTEGER
comment.range '0 - 0'
iface PCM
name 'Input Peak'
index 15
value.0 0
value.1 0
}
control.97 {
comment.access read
comment.type INTEGER
comment.range '0 - 0'
iface PCM
name 'Output Peak'
index 15
value.0 0
value.1 0
}
control.98 {
comment.access read
comment.type INTEGER
comment.range '0 - 0'
iface PCM
name 'Playback Peak'
index 15
value.0 0
value.1 0
}
control.99 {
comment.access read
comment.type INTEGER64
comment.range '0 - 0'
iface PCM
name 'Playback RMS'
index 15
value 0
}
control.100 {
comment.access read
comment.type INTEGER64
comment.range '0 - 0'
iface PCM
name 'Input RMS'
index 15
value 0
}
control.101 {
comment.access 'read write'
comment.type INTEGER
comment.range '0 - 65536 (step 1)'
iface MIXER
name Chn
index 16
value 0
}
control.102 {
comment.access read
comment.type INTEGER
comment.range '0 - 0'
iface PCM
name 'Input Peak'
index 16
value.0 0
value.1 0
}
control.103 {
comment.access read
comment.type INTEGER
comment.range '0 - 0'
iface PCM
name 'Output Peak'
index 16
value.0 0
value.1 0
}
control.104 {
comment.access read
comment.type INTEGER
comment.range '0 - 0'
iface PCM
name 'Playback Peak'
index 16
value.0 0
value.1 0
}
control.105 {
comment.access read
comment.type INTEGER64
comment.range '0 - 0'
iface PCM
name 'Playback RMS'
index 16
value 0
}
control.106 {
comment.access read
comment.type INTEGER64
comment.range '0 - 0'
iface PCM
name 'Input RMS'
index 16
value 0
}
control.107 {
comment.access 'read write'
comment.type INTEGER
comment.range '0 - 65536 (step 1)'
iface MIXER
name Chn
index 17
value 0
}
control.108 {
comment.access read
comment.type INTEGER
comment.range '0 - 0'
iface PCM
name 'Input Peak'
index 17
value.0 0
value.1 0
}
control.109 {
comment.access read
comment.type INTEGER
comment.range '0 - 0'
iface PCM
name 'Output Peak'
index 17
value.0 0
value.1 0
}
control.110 {
comment.access read
comment.type INTEGER
comment.range '0 - 0'
iface PCM
name 'Playback Peak'
index 17
value.0 0
value.1 0
}
control.111 {
comment.access read
comment.type INTEGER64
comment.range '0 - 0'
iface PCM
name 'Playback RMS'
index 17
value 0
}
control.112 {
comment.access read
comment.type INTEGER64
comment.range '0 - 0'
iface PCM
name 'Input RMS'
index 17
value 0
}
control.113 {
comment.access 'read write'
comment.type INTEGER
comment.range '0 - 65536 (step 1)'
iface MIXER
name Chn
index 18
value 0
}
control.114 {
comment.access read
comment.type INTEGER
comment.range '0 - 0'
iface PCM
name 'Input Peak'
index 18
value.0 0
value.1 0
}
control.115 {
comment.access read
comment.type INTEGER
comment.range '0 - 0'
iface PCM
name 'Output Peak'
index 18
value.0 0
value.1 0
}
control.116 {
comment.access read
comment.type INTEGER
comment.range '0 - 0'
iface PCM
name 'Playback Peak'
index 18
value.0 0
value.1 0
}
control.117 {
comment.access read
comment.type INTEGER64
comment.range '0 - 0'
iface PCM
name 'Playback RMS'
index 18
value 0
}
control.118 {
comment.access read
comment.type INTEGER64
comment.range '0 - 0'
iface PCM
name 'Input RMS'
index 18
value 0
}
control.119 {
comment.access 'read write'
comment.type INTEGER
comment.range '0 - 65536 (step 1)'
iface MIXER
name Chn
index 19
value 0
}
control.120 {
comment.access read
comment.type INTEGER
comment.range '0 - 0'
iface PCM
name 'Input Peak'
index 19
value.0 0
value.1 0
}
control.121 {
comment.access read
comment.type INTEGER
comment.range '0 - 0'
iface PCM
name 'Output Peak'
index 19
value.0 0
value.1 0
}
control.122 {
comment.access read
comment.type INTEGER
comment.range '0 - 0'
iface PCM
name 'Playback Peak'
index 19
value.0 0
value.1 0
}
control.123 {
comment.access read
comment.type INTEGER64
comment.range '0 - 0'
iface PCM
name 'Playback RMS'
index 19
value 0
}
control.124 {
comment.access read
comment.type INTEGER64
comment.range '0 - 0'
iface PCM
name 'Input RMS'
index 19
value 0
}
control.125 {
comment.access 'read write'
comment.type INTEGER
comment.range '0 - 65536 (step 1)'
iface MIXER
name Chn
index 20
value 0
}
control.126 {
comment.access read
comment.type INTEGER
comment.range '0 - 0'
iface PCM
name 'Input Peak'
index 20
value.0 0
value.1 0
}
control.127 {
comment.access read
comment.type INTEGER
comment.range '0 - 0'
iface PCM
name 'Output Peak'
index 20
value.0 0
value.1 0
}
control.128 {
comment.access read
comment.type INTEGER
comment.range '0 - 0'
iface PCM
name 'Playback Peak'
index 20
value.0 0
value.1 0
}
control.129 {
comment.access read
comment.type INTEGER64
comment.range '0 - 0'
iface PCM
name 'Playback RMS'
index 20
value 0
}
control.130 {
comment.access read
comment.type INTEGER64
comment.range '0 - 0'
iface PCM
name 'Input RMS'
index 20
value 0
}
control.131 {
comment.access 'read write'
comment.type INTEGER
comment.range '0 - 65536 (step 1)'
iface MIXER
name Chn
index 21
value 0
}
control.132 {
comment.access read
comment.type INTEGER
comment.range '0 - 0'
iface PCM
name 'Input Peak'
index 21
value.0 0
value.1 0
}
control.133 {
comment.access read
comment.type INTEGER
comment.range '0 - 0'
iface PCM
name 'Output Peak'
index 21
value.0 0
value.1 0
}
control.134 {
comment.access read
comment.type INTEGER
comment.range '0 - 0'
iface PCM
name 'Playback Peak'
index 21
value.0 0
value.1 0
}
control.135 {
comment.access read
comment.type INTEGER64
comment.range '0 - 0'
iface PCM
name 'Playback RMS'
index 21
value 0
}
control.136 {
comment.access read
comment.type INTEGER64
comment.range '0 - 0'
iface PCM
name 'Input RMS'
index 21
value 0
}
control.137 {
comment.access 'read write'
comment.type INTEGER
comment.range '0 - 65536 (step 1)'
iface MIXER
name Chn
index 22
value 0
}
control.138 {
comment.access read
comment.type INTEGER
comment.range '0 - 0'
iface PCM
name 'Input Peak'
index 22
value.0 0
value.1 0
}
control.139 {
comment.access read
comment.type INTEGER
comment.range '0 - 0'
iface PCM
name 'Output Peak'
index 22
value.0 0
value.1 0
}
control.140 {
comment.access read
comment.type INTEGER
comment.range '0 - 0'
iface PCM
name 'Playback Peak'
index 22
value.0 0
value.1 0
}
control.141 {
comment.access read
comment.type INTEGER64
comment.range '0 - 0'
iface PCM
name 'Playback RMS'
index 22
value 0
}
control.142 {
comment.access read
comment.type INTEGER64
comment.range '0 - 0'
iface PCM
name 'Input RMS'
index 22
value 0
}
control.143 {
comment.access 'read write'
comment.type INTEGER
comment.range '0 - 65536 (step 1)'
iface MIXER
name Chn
index 23
value 0
}
control.144 {
comment.access read
comment.type INTEGER
comment.range '0 - 0'
iface PCM
name 'Input Peak'
index 23
value.0 0
value.1 0
}
control.145 {
comment.access read
comment.type INTEGER
comment.range '0 - 0'
iface PCM
name 'Output Peak'
index 23
value.0 0
value.1 0
}
control.146 {
comment.access read
comment.type INTEGER
comment.range '0 - 0'
iface PCM
name 'Playback Peak'
index 23
value.0 0
value.1 0
}
control.147 {
comment.access read
comment.type INTEGER64
comment.range '0 - 0'
iface PCM
name 'Playback RMS'
index 23
value 0
}
control.148 {
comment.access read
comment.type INTEGER64
comment.range '0 - 0'
iface PCM
name 'Input RMS'
index 23
value 0
}
control.149 {
comment.access 'read write'
comment.type INTEGER
comment.range '0 - 65536 (step 1)'
iface MIXER
name Chn
index 24
value 0
}
control.150 {
comment.access read
comment.type INTEGER
comment.range '0 - 0'
iface PCM
name 'Input Peak'
index 24
value.0 0
value.1 0
}
control.151 {
comment.access read
comment.type INTEGER
comment.range '0 - 0'
iface PCM
name 'Output Peak'
index 24
value.0 0
value.1 0
}
control.152 {
comment.access read
comment.type INTEGER
comment.range '0 - 0'
iface PCM
name 'Playback Peak'
index 24
value.0 0
value.1 0
}
control.153 {
comment.access read
comment.type INTEGER64
comment.range '0 - 0'
iface PCM
name 'Playback RMS'
index 24
value 0
}
control.154 {
comment.access read
comment.type INTEGER64
comment.range '0 - 0'
iface PCM
name 'Input RMS'
index 24
value 0
}
control.155 {
comment.access 'read write'
comment.type INTEGER
comment.range '0 - 65536 (step 1)'
iface MIXER
name Chn
index 25
value 0
}
control.156 {
comment.access read
comment.type INTEGER
comment.range '0 - 0'
iface PCM
name 'Input Peak'
index 25
value.0 0
value.1 0
}
control.157 {
comment.access read
comment.type INTEGER
comment.range '0 - 0'
iface PCM
name 'Output Peak'
index 25
value.0 0
value.1 0
}
control.158 {
comment.access read
comment.type INTEGER
comment.range '0 - 0'
iface PCM
name 'Playback Peak'
index 25
value.0 0
value.1 0
}
control.159 {
comment.access read
comment.type INTEGER64
comment.range '0 - 0'
iface PCM
name 'Playback RMS'
index 25
value 0
}
control.160 {
comment.access read
comment.type INTEGER64
comment.range '0 - 0'
iface PCM
name 'Input RMS'
index 25
value 0
}
control.161 {
comment.access 'read write'
comment.type INTEGER
comment.range '0 - 65536 (step 1)'
iface MIXER
name Chn
index 26
value 0
}
control.162 {
comment.access read
comment.type INTEGER
comment.range '0 - 0'
iface PCM
name 'Input Peak'
index 26
value.0 0
value.1 0
}
control.163 {
comment.access read
comment.type INTEGER
comment.range '0 - 0'
iface PCM
name 'Output Peak'
index 26
value.0 0
value.1 0
}
control.164 {
comment.access read
comment.type INTEGER
comment.range '0 - 0'
iface PCM
name 'Playback Peak'
index 26
value.0 0
value.1 0
}
control.165 {
comment.access read
comment.type INTEGER64
comment.range '0 - 0'
iface PCM
name 'Playback RMS'
index 26
value 0
}
control.166 {
comment.access read
comment.type INTEGER64
comment.range '0 - 0'
iface PCM
name 'Input RMS'
index 26
value 0
}
}
^ permalink raw reply
* Re: [PATCH] SCSI Core patches
From: Patrick Mansfield @ 2003-01-08 1:36 UTC (permalink / raw)
To: Luben Tuikov; +Cc: linux-scsi
In-Reply-To: <3E1B513B.2090409@splentec.com>
On Tue, Jan 07, 2003 at 05:14:19PM -0500, Luben Tuikov wrote:
> Patrick Mansfield wrote:
> You must agree that the tuple (COMMAND, (lun, target, channel))
> doesn't say as much as (COMMAND, DEVICE).
Yes, but the current code simply sends a scsi_cmnd to the LLDD, and the
LLDD need only reference the scsi_cmnd.
> Anywhich way you look at it,
> this is a better abstraction.
Having the LLDD use more data structures does not imply a better
abstraction. Again, a better abstraction would be to use interfaces to
get the host/channel/target/lun. This could add overhead depending on the
implementation.
> For this reason you might consider the suggestions by Doug, or research moving
> multipathing higher up into the char/block layer, or thereabouts.
I have looked into putting multipath in the block layer, I've looked at
md, at the T3 code, and at the qlogic multi-path code. Code in the block
layer would be interesting, but might not solve problems with char
devices, and would need further abstractions on top of some multi-path
in the scsi layer (someone has to find and represent the devices and
paths, the block layer will not want to know about host/chan/target/lun,
nor will the block layer want to know details about scsi device or
transport errors).
> Somewhere between write(fd, buf, count) and scsi_request_fn(), multipathing
> will have to have already occured (ideally).
Putting the multipath abstraction into scsi_request_fn is IMO the best way
to go (as I've argued before) at least until other non-scsi block and
character devices support multi-pathing (maybe there are already
multi-path SATA devices, I don't know).
> > For scsi_device yes, but the LLDD does not have to look at scsi_device to
> > send a command, it can currently use the values found in scsi_cmnd.
>
> You see, by abstractizing this way, you get rid of redundancies,
> which let's you do all those nice things which Doug mentioned.
>
> Getting rid of redundancies in data design and code design is important.
>
As mentioned, using a scsi_device both for a list of paths and as a
representation of scsi device duplicates data in multiple places.
-- Patrick Mansfield
^ permalink raw reply
* Re: [parisc-linux] kernel panic when extracting large tar files
From: Carlos O'Donell @ 2003-01-08 1:34 UTC (permalink / raw)
To: Thibaut VARENE; +Cc: grundler, jsoe0708, markov, parisc-linux
In-Reply-To: <20030108002521.21a9c5e7.varenet@esiee.fr>
> > > FWIW, I experienced that bug too on the A500, had no time to chase it
> > > down but I will look at it soon.
> >
> > How big is the file? I routinely tar/untar _very_ large source archives
> > on my A500 and I see no problems.
> About 700M gzipped.
I just unpacked 1234744157 Jan 7 19:33 src.tar.gz into a 4GB source
archive on an ext2 fs. The box didn't even blink. Running 2.4.19-pa22
parisc64 non-SMP.
As it turns out Vlad's archive is on 14MB's but contains lots of very
small files. I'm trying to get a hold of this to test it out.
c.
^ permalink raw reply
* 2.5.54: ide-scsi still buggy?
From: Lukas Hejtmanek @ 2003-01-08 1:40 UTC (permalink / raw)
To: linux-kernel
Hello,
ide-scsi emulation does not work for drive /dev/hdg, why?
kernel boot parameters:
kernel /boot/vmlinuz-2.5.54bk3 ro root=/dev/hda1 ide=reverse vga=4 hdg=ide-scsi
It freezes kernel (sysrq do nothing) after lines:
scsi0 : SCSI host adapter emulation for IDE ATAPI devices
Vendor: TEAC Model: CD-W512EB Rev: 2
Type: CD-ROM ANSI SCSI revision: 02
scsi scan: host 0 channel 0 id 0 lun 0 identifier too long, length 60, max 50. Device might be improperly identified.
while attaching it to /dev/hde works ok. Why?
PDC20265: chipset revision 2
PDC20265: not 100% native mode: will probe irqs later
PDC20265: (U)DMA Burst Bit ENABLED Primary PCI Mode Secondary PCI Mode.
ide0: BM-DMA at 0x7800-0x7807, BIOS settings: hda:DMA, hdb:DMA
ide1: BM-DMA at 0x7808-0x780f, BIOS settings: hdc:DMA, hdd:pio
hda: ST380021A, ATA DISK drive
ide0 at 0x9000-0x9007,0x8802 on irq 10
hdc: IBM-DTLA-307045, ATA DISK drive
ide1 at 0x8400-0x8407,0x8002 on irq 10
VP_IDE: IDE controller at PCI slot 00:04.1
VP_IDE: chipset revision 16
VP_IDE: not 100% native mode: will probe irqs later
VP_IDE: VIA vt82c686a (rev 22) IDE UDMA66 controller on pci00:04.1
ide2: BM-DMA at 0xd800-0xd807, BIOS settings: hde:DMA, hdf:pio
ide3: BM-DMA at 0xd808-0xd80f, BIOS settings: hdg:DMA, hdh:pio
hde: DVD-ROM DDU1621, ATAPI CD/DVD-ROM drive
hde: DMA disabled
ide2 at 0x1f0-0x1f7,0x3f6 on irq 14
hdg: CD-W512EB, ATAPI CD/DVD-ROM drive
hdg: DMA disabled
^^^^^^^^^^^^^^^^^
hdparm reports:
/dev/hde:
HDIO_GET_MULTCOUNT failed: Inappropriate ioctl for device
IO_support = 1 (32-bit)
unmaskirq = 1 (on)
using_dma = 1 (on)
--
Lukáš Hejtmánek
^ permalink raw reply
* Re: 2.4.20 - ntfilter (owner) problems
From: blkcore @ 2003-01-08 1:26 UTC (permalink / raw)
To: netfilter
In-Reply-To: <200301071852.00836.tscherf@web.de>
You don't need a -j target to use the owner module, I use it for bandwidth
byte/counter logging, but heres some output for you to read.
[root@scsi1 root]# uname -r
2.4.20-grsec
[root@scsi1 root]# iptables -I OUTPUT -m owner --uid-owner root -j ACCEPT
iptables: Target problem
laptop:~# uname -r
2.4.19
laptop:~# iptables -I OUTPUT -m owner --uid-owner root
laptop:~# iptables -I OUTPUT -m owner --uid-owner root -j ACCEPT
laptop:~#
----- Original Message -----
From: "Thorsten Scherf" <tscherf@web.de>
To: "blkcore" <netfilter@blackcore.net>; <netfilter@lists.netfilter.org>
Sent: Tuesday, January 07, 2003 3:19 PM
Subject: Re: 2.4.20 - ntfilter (owner) problems
> I recently compiled 2.4.20 with netfilter support, with the owner module
> (-m owner), and after several attempts of trying to use it (worked for
> 2.4.18), it gives an error.
>
> [root@scsi1 slinksi]# iptables -I OUTPUT -m owner --uid-owner root
> iptables: Target problem
Where is your target?! Is see no one!
^ permalink raw reply
* problems while burning
From: Andreas Pakulat @ 2003-01-08 1:25 UTC (permalink / raw)
To: linux-kernel
[-- Attachment #1: Type: text/plain, Size: 3928 bytes --]
Hi,
I'm new to this list and already searched the archive, but didn't find
anything that helped.
My Problem is the following:
I've got a LiteOn Lt12101B IDE CD Burner here and it causes Kernel
Panics once in a while. I cannot reproduce this safely, but it comes up
when the PC not only does the burning, but a make or a galeon session
also.
The first mysterious thing is that as far as I've tested until now, it
only comes up with cdrecord, cdrdao burns images without kernel panic.
For the hardware and that stuff:
I've got a PIII 500 MHz on a Tyan Tsunami AT (PIIX4 Chip). The primary
master is a SAMSUNG SV4002H with the following from
/proc/ide/hda/settings:
name value min max mode
---- ----- --- --- ----
current_speed 66 0 69 rw
init_speed 66 0 69 rw
io_32bit 1 0 3 rw
multcount 16 0 16 rw
pio_mode write-only 0 255 w
using_dma 1 0 1 rw
primary slave is a Mistumi FX4820T with settings:
name value min max mode
---- ----- --- --- ----
current_speed 66 0 69 rw
init_speed 66 0 69 rw
io_32bit 1 0 3 rw
pio_mode write-only 0 255 w
using_dma 1 0 1 rw
secondary master is the LITE-ON LTR-12101B
with setting:
name value min max mode
---- ----- --- --- ----
current_speed 34 0 69 rw
init_speed 34 0 69 rw
io_32bit 0 0 3 rw
pio_mode write-only 0 255 w
using_dma 1 0 1 rw
and the secondary Slave is a Maxtor 91360U4 with settings:
name value min max mode
---- ----- --- --- ----
current_speed 66 0 69 rw
init_speed 66 0 69 rw
io_32bit 1 0 3 rw
multcount 16 0 16 rw
pio_mode write-only 0 255 w
using_dma 1 0 1 rw
The Image lies on the primary HDD and the cdrecord call is:
| cdrecord -VVVV debug=7 -kd=7 -vvvv -fs=16m dev=0,1,0 \
| timeout=60 driveropts=burnfree -xa2 iso.bin
The Bin-Iso-image was made with cdrdao, but it also happens with
mkisofs-created ones. I can also remove all switches and it still
hapens.
Sometimes there is somethins in /var/log/messages:
In some cases I get:
| Dec 19 18:06:38 debian kernel: scsi : aborting command due to timeout :
| pid 4561
| , scsi0, channel 0, id 1, lun 0 0x2a 00 00 01 f0 ba 00 00 1f 00
| Dec 19 18:06:38 debian kernel: hdc: timeout waiting for DMA
| Dec 19 18:06:38 debian kernel: ide_dmaproc: chipset supported
| ide_dma_timeout fu
| nc only: 14
| Dec 19 18:06:38 debian kernel: hdc: status timeout: status=0xd8 { Busy }
| Dec 19 18:06:38 debian kernel: hdc: drive not ready for command
| Dec 19 18:07:08 debian kernel: hdc: ATAPI reset timed-out, status=0x88
| Dec 19 18:07:08 debian kernel: hdd: DMA disabled
| Dec 19 18:07:13 debian kernel: scsi : aborting command due to timeout :
| pid 4561
| , scsi0, channel 0, id 1, lun 0 0x2a 00 00 01 f0 ba 00 00 1f 00
| Dec 19 18:07:13 debian kernel: SCSI host 0 abort (pid 4561) timed out -
| resetting
And so on, until I reset the system.
And 2 times in the last 4 I got:
| Jan 7 20:40:17 debian kernel: scsi : aborting command due to timeout :
| pid 1356
| 4, scsi0, channel 0, id 1, lun 0 0x2a 00 00 00 4c 69 00 00 1f 00
| Jan 7 20:40:17 debian kernel: hdc: timeout waiting for DMA
| Jan 7 20:40:17 debian kernel: ide_dmaproc: chipset supported
| ide_dma_timeout fu
| nc only: 14
| Jan 7 20:40:17 debian kernel: hdd: status timeout: status=0xd8 { Busy }
| Jan 7 20:40:17 debian kernel: hdd: DMA disabled
| Jan 7 20:40:17 debian kernel: hdd: drive not ready for command
| Jan 7 20:40:17 debian kernel: ide1: reset: master: error (0x00?)
I havn't got the time to try to disable dma with hdparm -d0 or to reduce
the speed of the cdburner to something below 34 (which is mdma? right).
Is there something else that can be done about this?
Ooops I forgot: Kernel is 2.4.20 from debian packages, I can send the
config if it is needed.
Andreas
--
Gut ist auch das Emporkommen von Linux als Herausforderer von Microsoft.
-- CDU-Vorsitzende Angela Merkel
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [2.5.54-dj1-bk] Some interesting experiences...
From: Joshua Kwan @ 2003-01-08 1:21 UTC (permalink / raw)
To: linux-kernel; +Cc: jsimmons, dahinds
[-- Attachment #1: Type: text/plain, Size: 3480 bytes --]
So I pulled 2.5 bk, James' fbdev updates and linux-dj, and built.
Here are some things here and there that I have noticed so far:
(note [linux-dj] means i think it's the result of pulling from that;
[linux-2.5] means i think it's a problem with the main tree;
[fbdev] means i think it's James' problem :))
1. [linux-dj] (i think?) after pulling linux-dj i noticed that the
references to 'font.h' in drivers/video/console were broken. They were
like#include "font.h" - I have fixed this to refer to the right font.h
(#include <linux/font.h>)...
...But for some reason bk edit fails in 2.5. Says it can't plock the
files i want to edit. Any idea what's up here? I can't make a patch now
:(
2. [linux-2.5] pcmcia-cs 3.2.3 will no longer build: here is the build
log, pertinent details only.
cc -MD -O3 -Wall -Wstrict-prototypes -pipe -Wa,--no-warn
-I../include/static -I/usr/src/linux-2.5/include -I../include
-I../modules -c cardmgr.c
In file included from cardmgr.c:200:
/usr/src/linux-2.5/include/scsi/scsi.h:185: parse error before "u8"
/usr/src/linux-2.5/include/scsi/scsi.h:185: warning: no semicolon at end
of struct or union
/usr/src/linux-2.5/include/scsi/scsi.h:186: warning: type defaults to
`int' in declaration of`ScsiLun'
/usr/src/linux-2.5/include/scsi/scsi.h:186: warning: data definition has
no type or storage class
make[1]: *** [cardmgr.o] Error
This occurs also in whatever NEW stuff there is on the pcmcia-cs web
area. This occurs with or without having pulled -dj.
SCSI is not part of my kernel. Might this have anything to do with it?
3. [linux-2.5] PS/2 mouse goes haywire every 30 seconds or so of use.
dmesg sayeth:
mice: PS/2 mouse device common for all mice
input: PS/2 Synaptics TouchPad on isa0060/serio4
but more importantly this is the cause:
psmouse.c: Lost synchronization, throwing 2 bytes away.
psmouse.c: Lost synchronization, throwing 2 bytes away.
This happens on my desktop machine running 2.5.54mm3 (release) as well.
varies between 1/2 bytes.
4. [fbdev] random junk on screen at boot using radeonfb, and no blinking
cursor. 'nuff said. James, I already told you this but never cc'd it to
the mailing list so I'm saying it here just for the record.
dmesg sayeth:
radeonfb_pci_register BEGIN
radeonfb: ref_clk=2700, ref_div=60, xclk=17500 from BIOS
radeonfb: probed DDR SGRAM 32768k videoram
radeon_get_moninfo: bios 4 scratch = 10000c4
radeonfb: panel ID string: 1024x768
radeonfb: detected DFP panel size from BIOS: 1024x768
radeonfb: ATI Radeon M6 LY DDR SGRAM 32 MB
radeonfb: DVI port LCD monitor connected
radeonfb: CRT port no monitor connected
radeonfb_pci_register END
[drm] Initialized radeon 1.7.0 20020828 on minor 0
but i doubt any of this is any use because it shows a bit AFTER the
resolution has actually changed.
5. [unsure] When poking around in /proc/acpi this stuff shows up in
kernel log/dmesg:
ACPI-0250: *** Error: Looking up [BUF0] in namespace,
AE_ALREADY_EXISTS
ACPI-1102: *** Error: Method execution failed
[\_SB_.BAT0._BST] (Node cff4b940), AE_ALREADY_EXISTS
This is an i845 Intel chipset. Doesn't affect usability, though.
Hope this helps development - I have my .config up at
http://ludicrus.ath.cx/~joshk/kernconf for whoever needs to refer to it.
2.5.54 is still great, btw :D
Regards
Josh
--
Joshua Kwan
joshk@mspencer.net
pgp public key at http://joshk.mspencer.net/pubkey_gpg.asc
It's hard to keep your shirt on when you're getting something off your
chest.
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: 2.5.54 - quota support
From: Lukas Hejtmanek @ 2003-01-08 1:21 UTC (permalink / raw)
To: Jan Kara; +Cc: Andrew Morton, linux-kernel
In-Reply-To: <20030107164028.GC6719@atrey.karlin.mff.cuni.cz>
On Tue, Jan 07, 2003 at 05:40:28PM +0100, Jan Kara wrote:
> Reporting 'No such device' was actually bug which was introduced some
> time ago but nobody probably noticed it... It was introduce when quota
> code was converted from device numbers to 'bdev' structures.
> I also fixed one bug in quotaon() call however I'm not sure wheter it
> could cause the freeze. Anyway patch is attached, try it and tell me
> about the changes.
Hmm, quotaon / with init=/bin/sh seems to work OK, quota accounting is made and
repquota displays normal info.
However with normal startup quotaon / still freezes :-(
Btw, does anyone know why mount is failing for so long time while using with
automount? Process mount is in uninterruptible sleep for more than 10 secs until
reports no disc in cdrom. (the same for my usb camera when autofs try to mount
it while it is not connected).
--
Lukáš Hejtmánek
^ permalink raw reply
* Re: [PATCH] Set TIF_IRET in more places
From: Richard Henderson @ 2003-01-08 1:21 UTC (permalink / raw)
To: Zack Weinberg; +Cc: Jamie Lokier, linux-kernel, torvalds
In-Reply-To: <87of6s3gm3.fsf@egil.codesourcery.com>
On Tue, Jan 07, 2003 at 11:27:32AM -0800, Zack Weinberg wrote:
> > It explicitly checks for the opcode sequences 0x58b877000000cd80 and
> > 0xb8ad000000cd80 in order to unwind exception frames around a
> > handled signal. Ugly, isn't it?
>
> We're open to better ideas ...
Something like having dwarf2 unwind information for the
vsyscall page on the page as well?
r~
^ permalink raw reply
* Re: Set the "mail system".
From: Jude DaShiell @ 2003-01-08 1:05 UTC (permalink / raw)
To: Jose Luis Alarcon; +Cc: linux-newbie
In-Reply-To: <20030107190203.26D873E2F@sitemail.everyone.net>
Sounds like both fetchmail and sendmail need configuring or alternatively
to sendmail there's postfix or exim. If the system runs sendmail the
package will have to be turned off and possibly uninstalled if you go with
one of the alternatives. On this machine whenever I run as root one of
the things that happens when I start that account up is the internet
connection gets taken down then brought back up on reboot. If you have
the linux howtos installed on your system take a look at
sendmail-address-rewriting-howto. It has the necessary configuration
steps you'll ned to get sendmail configured.
--
Jude <dashielljt(at)gmpexpress-dot-net>
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs
^ permalink raw reply
* Re: Honest does not pay here ...
From: Andre Hedrick @ 2003-01-08 1:10 UTC (permalink / raw)
To: venom; +Cc: Larry McVoy, Matthias Andree, linux-kernel
In-Reply-To: <Pine.LNX.4.43.0301080152130.25245-100000@cibs9.sns.it>
Luigi,
You forgot one thing. None of us can control what the end user does.
If a vendor tells the enduser to alter the 2.5/2.6 kernel and recompile.
What are you going to do?
Add a clause where the enduser can not change the source code or apply a
patch to do it for them?
Funny, you lost your rights to do that w/ GPL, as did I.
*sigh*
Andre Hedrick
LAD Storage Consulting Group
On Wed, 8 Jan 2003 venom@sns.it wrote:
>
> well, I was forgetting to specify,
> queues are kernel threads, and that is quite
> optimum expecially on SMP systems.
> One big advantage is that conflicts possibilities are
> (should be) less than minimal.
>
> Luigi
>
> On Tue, 7 Jan 2003, Larry McVoy wrote:
>
> > Date: Tue, 7 Jan 2003 16:30:50 -0800
> > From: Larry McVoy <lm@bitmover.com>
> > To: venom@sns.it
> > Cc: Matthias Andree <matthias.andree@gmx.de>, linux-kernel@vger.kernel.org,
> > andre@linux-ide.org
> > Subject: Re: Honest does not pay here ...
> >
> >
> > > In very semplicistic words:
> > > In 2.5/2.6 kernels, non GPL modules have a big
> > > penalty, because they cannot create their own queue, but have to use a default
> > > one.
> >
> > I may be showing my ignorance here (won't be the first time) but this makes
> > me wonder if Linux could provide a way to do "user level drivers". I.e.,
> > drivers which ran in kernel mode but in the context of a process and had
> > to talk to the real kernel via pipes or whatever. It's a fair amount of
> > plumbing but could have the advantage of being a more stable interface
> > for the drivers.
> >
> > If you think about it, drivers are more or less open/close/read/write/ioctl.
> > They need kernel privileges to do their thing but don't need (and shouldn't
> > have) access to all the guts of the kernel.
> >
> > Can any well traveled driver people see this working or is it nuts?
> > --
> > ---
> > Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
> >
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
^ permalink raw reply
* RE: netfilter digest, Vol 1 #513 - 12 msgs
From: Bob Balsover @ 2003-01-08 1:01 UTC (permalink / raw)
To: netfilter
In-Reply-To: <20030107220901.9462.47110.Mailman@kashyyyk>
Message: 9
Date: Tue, 7 Jan 2003 21:13:34 +0100
From: Harald Welte <laforge@netfilter.org>
To: Netfilter Development Mailinglist
<netfilter-devel@lists.netfilter.org>
Cc: Netfilter Mailinglist <netfilter@lists.netfilter.org>,
Netfilter Announcement List
<netfilter-announce@lists.netfilter.org>
Subject: [ANNOUNCE] New netfilter/iptables patch-o-matic release
Reply-To: coreteam@netfilter.org
--KMIs29sPfC/9Gbii
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
While patch-o-matic-20030107 is announced on the home page, it is not
listed on the download page...
------------------------------------------
Good news, Everyone! (TM)
The netfilter core team announces a new release of the netfilter
patch-o-matic suite:
patch-o-matic-20030107
This release contains the most up-to-date bugfixes and new features
for=20
the netfilter/iptables subsystem of the 2.4.x Linux kernel.
The patches are devided into several repositories. Which ones are to be
used, depends on how conservative or adventurous the user is ;)
'submitted':
Patches which have been submitted for kernel inclusion, most of
them have already appeared in 2.4.20. It's really recommended
to always apply those
'pending':
Patches currently pending for kernel inclusion. They will
almost certainly appear in the next official kernel release.
'base':
New features which are self-contained enough so it's sure they
don't clash with each other. Those are safe in the way that
they
don't harm already existing functionality. Playing with them
might discover one or the other remaining bug... you've been
warned.
'extra':
New features which might cause other patches from 'extra' to
clash with each other. Most interestingly, you will find here
conntrack/nat helpers for H.323, PPTP, talk/ntalk, rsh, tftp,
mms and amanda.
Read more about the individual patches of this new patch-o-matic release
at: http://www.netfilter.org/documentation/pomlist/pom-summary.html
The new patch-o-matic release including a cryptographic GPG signature
is available for download at
http://www.netfilter.org/downloads.html#pom-20030107
Enjoy,
Harald (for the netfilter core team)
^ permalink raw reply
* Re: Honest does not pay here ...
From: Matthias Andree @ 2003-01-08 1:10 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <20030108003050.GF17310@work.bitmover.com>
On Tue, 07 Jan 2003, Larry McVoy wrote:
>
> > In very semplicistic words:
> > In 2.5/2.6 kernels, non GPL modules have a big
> > penalty, because they cannot create their own queue, but have to use a default
> > one.
>
> I may be showing my ignorance here (won't be the first time) but this makes
> me wonder if Linux could provide a way to do "user level drivers". I.e.,
> drivers which ran in kernel mode but in the context of a process and had
> to talk to the real kernel via pipes or whatever. It's a fair amount of
> plumbing but could have the advantage of being a more stable interface
> for the drivers.
Some parts of the kernel have opened up for user space, think the
user-space file system efforts as one example.
^ permalink raw reply
* [PATCH] add scsi_level and revision support to lsscsci 0.03
From: Patrick Mansfield @ 2003-01-08 1:00 UTC (permalink / raw)
To: Douglas Gilbert, linux-scsi
Doug -
This patch adds support for use of scsi_level and the output of revision
to lsscsi 0.03. It should work even without scsi_level in the scsi sysfs
attributes.
lsscsi -c now gives the exact same output as catting /proc/scsi/scsi.
--- lsscsi.c-orig Tue Jan 7 15:55:25 2003
+++ lsscsi.c Tue Jan 7 15:56:25 2003
@@ -221,7 +221,7 @@
int hcil_arr[4];
char buff[NAME_LEN_MAX];
char value[NAME_LEN_MAX];
- int type, k;
+ int type, scsi_level, k;
strcpy(buff, dir_name);
strcat(buff, "/");
@@ -254,7 +254,13 @@
printf(" Type: %-33s", "???");
} else
printf(" Type: %-33s", scsi_device_types[type]);
- printf("ANSI SCSI revision: ??\n");
+ if (! get_value(buff, "scsi_level", value, NAME_LEN_MAX)) {
+ printf("ANSI SCSI revision: ?\n");
+ } else if (1 != sscanf(value, "%d", &scsi_level)) {
+ printf("ANSI SCSI revision: ??\n");
+ } else
+ printf("ANSI SCSI revision: %02x\n", (scsi_level - 1) ?
+ scsi_level - 1 : 1);
if (out_mask & MASK_NAME) {
if (get_value(buff, "name", value, NAME_LEN_MAX))
printf(" name: %s\n", value);
-- Patrick Mansfield
^ permalink raw reply
* Re: Linux iSCSI Initiator, OpenSource (fwd) (Re: Gauntlet Set NOW!)
From: Larry McVoy @ 2003-01-08 1:08 UTC (permalink / raw)
To: Alan Cox; +Cc: Roman Zippel, Andre Hedrick, Linux Kernel Mailing List
In-Reply-To: <1041990181.22457.9.camel@irongate.swansea.linux.org.uk>
On Wed, Jan 08, 2003 at 01:43:01AM +0000, Alan Cox wrote:
> On Wed, 2003-01-08 at 00:04, Roman Zippel wrote:
> > If you want to compare apples with apples, you should rather tell me how
> > I turn off the checksumming of my nic.
>
> For some cards you can do this. For instructive information on the effects
> look at the saga of sunos 3.x and NFS over wans. Old SunOS turned off UDP
> checksums for NFS. It provided an adequate demonstration that UDP checksums
> for NFS are needed. Sun of course addressed this design error long long
> ago.
BK has a pretty lame checksum but good enough to catch a lot of errors
and we still catch 'em. Software, hardware, network, whatever, they
happen all the time.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
^ permalink raw reply
* Re: Linux iSCSI Initiator, OpenSource (fwd) (Re: Gauntlet Set NOW!)
From: walt @ 2003-01-08 1:07 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <fa.hjtum4v.fki8p1@ifi.uio.no>
Andre Hedrick wrote:
> Richard,
>
> Can you admit the follow, that GPL has everything to control
> redistribution, and has ZERO context for copyright. The holders of the
> copyright control the issues.
RMS didn't understand this paragraph, and neither did I. Would you
please clarify?
> See your whole hook is "Derivative Works" well, I implimented a protocol.
> It works regardless of platform or OS. All it uses are simple and
> standard kernel services.
If you did this because of RMS or his GPL then I think all of us owe him
a big 'thank you'.
Andre, I've been following this list for at least two years. Although I
contribute nothing except an occasional bug report I care about what
happens here and I and I care about the people who do contribute. I know
that includes you -- in a big way.
Please let me make some observations:
1) I admire anyone who speaks more than one language. I suspect that
includes you.
2) Much of the time I don't know what the hell you're talking about.
(I'll bet you a Porsche that I'm not the only one ;-)
3) You'll make back your expenses a lot faster if you'll get rid of
the Porsche.
4) I thank you for all your contributions to Open Source. I benefit
from your work every day and I want you to know that I appreciate it.
^ permalink raw reply
* Re: [PATCH 1/3] High-res-timers part 1 (core) take 23
From: george anzinger @ 2003-01-08 0:05 UTC (permalink / raw)
To: Randy.Dunlap; +Cc: Linus Torvalds, linux-kernel@vger.kernel.org
In-Reply-To: <Pine.LNX.4.33L2.0301071111210.2498-100000@dragon.pdx.osdl.net>
"Randy.Dunlap" wrote:
>
> Hi George,
>
> On Fri, 3 Jan 2003, george anzinger wrote:
>
> | Just in case you might like high res timers...
> |
> | Now for 2.5.54-bk1
>
> Using exactly 2.5.54-bk1 + the POSIX clocks/timers + HRT patches,
> when I run the HRT support test suite (do_test), I'm getting
> intermittent (but often) spinlock BUGs. I've done this both without
> and with HIGH_RES_TIMERS enabled (i.e., different kernels built
> in the same source tree).
> Details are below.
>
> Yes, I expect to be able to run the test suite on a kernel that
> doesn't have HIGH_RES_TIMERS enabled...and to see the tests fail.
Actually the tests should detect low res and adapt
reasonably well. The one problem(?)is that the
clock_nanosleep test finds the kernel timing bug introduced
by not pushing the wall clock 1/HZ on a tick. (The current
2.5 kernel actually pushes time a bit more than this
introducing a difference in the rate of time passing between
the wall clock an the jiffies. This causes timers to expire
early which is a big NO-NO, standard wise.)
This is most easily seen by doing:
time sleep 60
and noticing that it completes in less than 60 seconds, even
with the scheduling overhead.
>
> | -------
> | This patch supplies the core changes to implement high
> | resolution timers. Mostly it changes the timer list from
> | the multi stage hash (or cascade) list to a single stage
> | hash list. This change makes it easy to configure the list
> | size for those who are concerned with performance. It also
> | eliminates the "time out" for the cascade operation every
> | 512 jiffies, thus eliminating possibly long preemption
> | times. On input from Stephen Hemminger<shemminger@osdl.org>
> | the configuration of the timer list size is no longer
> | presented as a configure option. The code can still be
> | change (one line) to use larger or smaller lists.
> |
> | With this patch applied, the system should boot and run much
> | as it does prior to the patch. This patch depends on the
> | POSIX clocks & timers patch in that it assumes the changes
> | that patch made to timer.c to remove timer_t. This
> | dependency can be removed if needed.
>
> Couple of questions, please:
>
> 1. With HIGH_RES_TIMERS enabled, are all timers high-res timers,
> or does the API allow for some non-high-res timers (regular/normal)
> and some high-res-timers?
Actually you are asking a couple of questions here. First,
the API (POSIX clocks & timers) is extended in the high res
patch to add two new clocks:
CLOCK_REALTIME_HR
CLOCK_MONOTONIC_HR
Only calls using these clocks will generate the high-res
overhead (usually an interrupt is required that is somewhere
between two 1/HZ interrupts).
On the other hand, the timers list handling code was
expanded to handle sub jiffie values (but only the above API
can set these values) so there is a small (very small)
addition in timer handling to at least test that the sub
jiffie is zero.
Normal timers, i.e. setitimer, select, time_schedule, etc.
all use the normal low res timers so nothing changes here.
>
> 2. With HIGH_RES_TIMERS enabled and no apps trying to use high-res
> timers, should I be able to detect any additional system overhead
> due to the HIGH_RES_TIMERS code?
You would need a very sensitive tool to detect any
additional overhead. Still, as I mentioned above, there is
some.
>
> Thanks,
And thank you for the bug report.
-g
> --
> ~Randy
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 2.5.54-bk1 + POSIX/HRT patches, with HIGH_RES_TIMERS=n:
>
> kernel BUG at include/asm/spinlock.h:123!
> invalid operand: 0000
> CPU: 1
> EIP: 0060:[<c0130260>] Not tainted
> EFLAGS: 00010086
> EIP is at good_timespec+0x80/0x180
> eax: 0000000e ebx: ee5c471c ecx: f63d7100 edx: c03e2dec
> esi: 00000000 edi: ed50df9c ebp: ed50df8c esp: ed50df78
> ds: 007b es: 007b ss: 0068
> Process timer_test (pid: 1970, threadinfo=ed50c000 task=f5b85800)
> Stack: c0369bc0 c0130244 ed50c000 ed50df9c 00000000 ed50dfbc c01308d6 00000000
> ed50df9c 00000082 c0150e73 f7193ce4 40016000 00000032 ed50c000 4001526c
> 00000000 bfff9778 c0109537 00000000 00000000 bfff90a8 4001526c 00000000
> Call Trace:
> [<c0130244>] good_timespec+0x64/0x180
> [<c01308d6>] sys_timer_settime+0x16/0x180
> [<c0150e73>] sys_read+0x33/0x40
> [<c0109537>] system_call+0x7/0xb
>
> Code: 0f 0b 7b 00 64 98 36 c0 59 58 8d b6 00 00 00 00 f0 fe 4b 08
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 2.5.54-bk1 + POSIX/HRT patches, with HIGH_RES_TIMERS=y:
>
> kernel BUG at include/asm/spinlock.h:123!
> invalid operand: 0000
> CPU: 0
> EIP: 0060:[<c01307a0>] Not tainted
> EFLAGS: 00010086
> EIP is at good_timespec+0x80/0x180
> eax: 0000000e ebx: f68c589c ecx: f6f96300 edx: c03e3aec
> esi: 87000007 edi: f6919ed8 ebp: f6919ec8 esp: f6919eb4
> ds: 007b es: 007b ss: 0068
> Process 2timer_test (pid: 1940, threadinfo=f6918000 task=f6bc6b80)
> Stack: c036a860 c0130784 00000023 f6919f30 00000001 f6919ee4 c01300b8 87000007
> f6919ed8 00000086 00000023 f6919f30 f6919efc c0127117 f6919f30 f6919f30
> f6bc7130 f6918000 f6919f1c c012829a f6bc7130 f6919f30 f6bc7130 f6919fc4
> Call Trace:
> [<c0130784>] good_timespec+0x64/0x180
> [<c01300b8>] schedule_next_timer+0x18/0x50
> [<c0127117>] __dequeue_signal+0x87/0xa0
> [<c012829a>] notify_parent+0x7a/0x290
> [<c01092cd>] handle_signal+0x5d/0xd0
> [<c0222e5f>] copy_to_user+0x2f/0x40
> [<c01285ea>] do_no_restart_syscall+0x10a/0x240
> [<c0109582>] work_resched+0x13/0x15
>
> Code: 0f 0b 7b 00 04 a5 36 c0 59 58 8d b6 00 00 00 00 f0 fe 4b 08
>
> ###
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
George Anzinger george@mvista.com
High-res-timers:
http://sourceforge.net/projects/high-res-timers/
Preemption patch:
http://www.kernel.org/pub/linux/kernel/people/rml
^ permalink raw reply
* [PATCH] resend add scsi_level to scsi_device sysfs attributes
From: Patrick Mansfield @ 2003-01-08 0:56 UTC (permalink / raw)
To: JEJ Bottomley, linux-scsi
In-Reply-To: <20030107165324.A17719@beaverton.ibm.com>
Hi -
[Resending and cc-ing linux-scsi properly.]
This simple patch adds scsi_level to the scsi_device sysfs attributes,
mainly for use with Doug Gilbert's lsscsi program.
--- 1.2/drivers/scsi/scsi_sysfs.c Tue Dec 3 00:53:21 2002
+++ edited/drivers/scsi/scsi_sysfs.c Mon Dec 30 14:11:10 2002
@@ -224,6 +224,7 @@
sdev_rd_attr (current_queue_depth, "%d\n");
sdev_rd_attr (new_queue_depth, "%d\n");
sdev_rd_attr (type, "%d\n");
+sdev_rd_attr (scsi_level, "%d\n");
sdev_rd_attr (access_count, "%d\n");
sdev_rd_attr (vendor, "%.8s\n");
sdev_rd_attr (model, "%.16s\n");
@@ -235,6 +236,7 @@
&dev_attr_current_queue_depth,
&dev_attr_new_queue_depth,
&dev_attr_type,
+ &dev_attr_scsi_level,
&dev_attr_access_count,
&dev_attr_vendor,
&dev_attr_model,
-- Patrick Mansfield
^ permalink raw reply
* Re: Linux iSCSI Initiator, OpenSource (fwd) (Re: Gauntlet Set NOW!)
From: Alan Cox @ 2003-01-08 1:43 UTC (permalink / raw)
To: Roman Zippel; +Cc: Andre Hedrick, Linux Kernel Mailing List
In-Reply-To: <3E1B6B23.40A3C939@linux-m68k.org>
On Wed, 2003-01-08 at 00:04, Roman Zippel wrote:
> If you want to compare apples with apples, you should rather tell me how
> I turn off the checksumming of my nic.
For some cards you can do this. For instructive information on the effects
look at the saga of sunos 3.x and NFS over wans. Old SunOS turned off UDP
checksums for NFS. It provided an adequate demonstration that UDP checksums
for NFS are needed. Sun of course addressed this design error long long
ago.
^ permalink raw reply
* RE: PIC programming question
From: Joshua Hayworth @ 2003-01-08 0:48 UTC (permalink / raw)
To: 'Phil', linux-hams
In-Reply-To: <E51999353E6CF54E856A3193EF0686CC34F9D9@actmail>
Is this what your talking about?
http://home3.inet.tele.dk/frda/picasm/prog.html
Just curious,
-- Joshua
P.s. My grandfather gave me the coolest gift for christmas. It was a
copy of the ARRL Amateur Radio Handbook circa 1958. For my birthday
(January 3rd) I got a $100 gift certificate to Frys Electronics. With
that I bought the 2003 edition of the Handbook and the W5YI Technician
class (Element 2) study guide. I'm going to my first HAM Club meeting
tonight. This hobby is turning out to be really cool.
<shrug>
Just thought you guys should know... ;-)
-----Original Message-----
From: linux-hams-owner@vger.kernel.org
[mailto:linux-hams-owner@vger.kernel.org] On Behalf Of Phil
Sent: Monday, January 06, 2003 08:31 PM
To: linux-hams@vger.kernel.org
Subject: PIC programming question
Hello All,
I'd to try my hand at PIC programming and the projects that I have in
mind are
amateur radio related so I suppose this question is not off topic.
I have some utilities (gputils) that will create the hex code, however
I'm
wondering what other people use to actually program the PIC.
An Internet search didn't reveal very many programmers for Linux. One
interesting project is called ponyprog2000. The hardware is more complex
than
a typical programmer that operates under MS Windows but it's probably
more
versatile. The software appears to be easy enough to use.
Does anyone have a favorite PIC programmer? My only interest at the
moment is
to be able to program PIC 16F84 and 16F876 chips.
--
Regards,
Phil
phil@spiderweb.com.au
-
To unsubscribe from this list: send the line "unsubscribe linux-hams" in
the body of a message to majordomo@vger.kernel.org More majordomo info
at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* 3CR990 question (Nearly unrelated to iSCSI)
From: nick @ 2003-01-08 0:56 UTC (permalink / raw)
To: linux-kernel
On Wed, 8 Jan 2003, Andrew McGregor wrote:
> > AH permits multiple digests, they also happen to correspond to the
> > hardware accelerated ones on things like the 3c990...
Speaking of which, did this driver which was mentioned ever occur?
Nick
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.