Re: [Dorset] Xorg hangs on upgrade from Debian Lenny to Squeeze
Hi Ralph On 25/02/11 01:19, Ralph Corderoy wrote: Hi Tim, I've upgraded a machine with ATI Rage128 from Lenny to Squeeze. The machine hangs (totally) on bringing up X, /var/log/X.0.log showing R128CCEWaitForIdle: CCE stop -9, start -9, idle -9, Idle timed out, resetting engine for ever, so it's a driver problem. So far I've tried generating a new xorg.conf with Xorg -configure (no improvement). Driver is r128. Any advice much appreciated. Have you tried disabling all hardware acceleration, just to see if that improves things in the short term? See option NoAccel in r128(4). I found various complaints about previously working R128-driven cards stopping working after upgrades, but nothing coherent that looked like it would help. Had tried NoAccel, and various other possible options without success. Morning googling often seems to be better than end-of-day searching - Solution turned out to be apt-get firmware-linux-nonfree Xorg -configure Copied over new xorg.conf to /etc/X11 Edited Driver r128 to Driver ati It's a pity this upgrade broke a pretty standard driver. Thanks for your help! Cheers Tim -- Next meeting: Blandford Forum, Wednesday 2011-03-02 20:00 Meets, Mailing list, IRC, LinkedIn, ... http://dorset.lug.org.uk/ How to Report Bugs Effectively: http://goo.gl/4Xue
Re: [Dorset] [OT] DNS port number
Hi Andrew, Once a connection is made (an incoming connect request to an allowed port) accept(2) will grab another port so that the original port is free for further connect requests. For the benefit of others, since I know you really know this already :-), accept(2) creates another *socket* to handle the connection that's been made, not another port, so further connection requests on the existing socket can be accepted. The port number is the same for both sockets; that's fine since the 5-tuple overall with be distinct between the two. Cheers, Ralph. -- Next meeting: Blandford Forum, Wednesday 2011-03-02 20:00 Meets, Mailing list, IRC, LinkedIn, ... http://dorset.lug.org.uk/ How to Report Bugs Effectively: http://goo.gl/4Xue
Re: [Dorset] [OT] DNS port number
On Friday, February 25, 2011 05:25:29 pm Ralph Corderoy wrote: Hi Andrew, Once a connection is made (an incoming connect request to an allowed port) accept(2) will grab another port so that the original port is free for further connect requests. For the benefit of others, since I know you really know this already :-), accept(2) creates another *socket* to handle the connection that's been made, not another port, so further connection requests on the existing socket can be accepted. The port number is the same for both sockets; that's fine since the 5-tuple overall with be distinct between the two. Cheers, Ralph. -- Next meeting: Blandford Forum, Wednesday 2011-03-02 20:00 Meets, Mailing list, IRC, LinkedIn, ... http://dorset.lug.org.uk/ How to Report Bugs Effectively: http://goo.gl/4Xue Yup! sincerest apologies. You are of course right - its the 5-tuple that identifies the endpoint. Andy -- Next meeting: Blandford Forum, Wednesday 2011-03-02 20:00 Meets, Mailing list, IRC, LinkedIn, ... http://dorset.lug.org.uk/ How to Report Bugs Effectively: http://goo.gl/4Xue
Re: [Dorset] Belkin wireless USB
Hi Peter,
$ lspci -vmmnn | awk 'BEGIN {RS = }
/Vendor:[^[]+*\[14e4\]/ {print $0, \n}'
Slot: 00:0a.0
Class:Network controller [0280]
Vendor: Broadcom Corporation [14e4]
Device: BCM4306 802.11b/g Wireless LAN Controller [4320]
SVendor: Wistron NeWeb Corp. [185f]
SDevice: Device [1220]
Rev: 03
Discussion on #dorset, particuarly thanks to John Carlyle-Clarke,
suggested that this is supported by the b43 driver. This was based on
http://wireless.kernel.org/en/users/Devices/PCI, select PCI vendor of
0x14e4 and PCI product 0x4320 to filter. Then looking for a PCI
Subvendor of 0x185f (based on your output above) gives just one match,
FormPCI PCI PCIPCI
Driver Vendor Product factor vendor product subvendor subsystem
b43 Linksys WMP54G PCI 0x14e4 0x4320 0x185f 0x1220
and that matches on the PCI Subsystem too.
Then http://wireless.kernel.org/en/users/Drivers/b43#Known_PCI_devices
has three entries for 14e4:4320. One's USB and can be ignored. The
other two vary depending on the chip you have; BCM4306/2 or BCM4306/3.
We guess that the `Rev: 03' you machine gives above means you've the
latter. The Modes and PHY version being `?' is somewhat disconcerting
but documentation is so often out of date. :-)
there's a lovely little switch on the laptop that turns the Wi-Fi on
and off...
...
So I suppose that I've actually asked the wrong question, what I
should have asked is How do I find out what input / signal the
processor sees when I press the shiny button
Consensus was that this bit will just work. These buttons tend to be
part of ACPI. Pressing them will cause an interrupt that filters up
through the kernel and pops out into userspace, probably through
/proc/acpi/event where it will cause something appropriate to happen.
As a start to checking this you could do
cat /proc/interrupts
then press and release the button and then repeat that command. Has the
count of the number of interrupts increased by one for any likely
looking interrupt source?
Cheers,
Ralph.
--
Next meeting: Blandford Forum, Wednesday 2011-03-02 20:00
Meets, Mailing list, IRC, LinkedIn, ... http://dorset.lug.org.uk/
How to Report Bugs Effectively: http://goo.gl/4Xue
