Hi Nicola, Not sure how much use this will be to you, but anyway: On Sun, 2003-02-02 at 14:50, Nicola Richmond wrote: > I have just acquired a Dell Latitude X200 (can I just say: ooo swanky!) > to test the modem. I have successfully managed to connect to Freeserve > (I get a message like CONNECT 46999) but then shortly afterwards get a > NO CARRIER message. I understand that this is a known bug in the driver > but that it's believed to be ISP dependent. That sounds a little odd, but vaguely believable, given it's a software modem. > Does anyone know if > freeserve could be the culprit and if so could someone recommend another > ISP (I'm currently paying £14/mth for unlimited use). If you're on an all-you-can-eat, then Freeserve will not be the culprit. Connectivity is provisioned via BT, who sell ISPs 'ports' (virtual modems) in their exchanges - so, the leg of the trip you're having problems with suggests it's a problem interfacing with the exchange. In which case, you can swap ISPs all you like and it won't make any difference (if you're sticking to all-you-can-eat). However, it might be worth trying some of the 0845 free signup ISPs, and see if it does make any difference: these types of connections are usually more reliable. It's not a solution, but it does at least allow you to figure out where the problem lies, and might aid future decisions. Alternatively, you could try turning the speed on the modem down to a 33.6 or something - the driver could be having problems getting enough CPU in time to process things, so throttling back a little might make the problem go away. I would go all the way back to 14.4 I think; just to be as sure as possible. > ohci1394 and sbp2 amongst others. It seems to recognise that there is a > CD drive but I can't mount it. You seem to be correct: > Jan 30 12:05:28 localhost /etc/hotplug/ieee1394.agent: Setup sbp2 for > IEEE1394 product 0x00065b/0x00609e/0x010483 > Jan 30 12:05:28 localhost kernel: ieee1394: sbp2: Logged into SBP-2 > device > Jan 30 12:05:28 localhost kernel: ieee1394: sbp2: Node[01:1023]: Max > speed [S400] - Max payload [2048] > Jan 30 12:05:28 localhost kernel: scsi0 : IEEE-1394 SBP-2 protocol > driver (host: ohci1394) > <snip> > Jan 30 12:07:14 localhost kernel: Attached scsi CD-ROM sr0 at scsi0, > channel 0, id 0, lun 0 > Jan 30 12:07:44 localhost kernel: ieee1394: sbp2: aborting sbp2 command :eek: > Jan 30 12:07:44 localhost kernel: Mode Sense 00 2a 00 80 00 > Jan 30 12:07:54 localhost kernel: ieee1394: sbp2: aborting sbp2 command > Jan 30 12:07:54 localhost kernel: Test Unit Ready 00 00 00 00 00 > Jan 30 12:07:54 localhost kernel: ieee1394: sbp2: reset requested > Jan 30 12:07:54 localhost kernel: ieee1394: sbp2: Generating IEEE-1394 > bus reset > Jan 30 12:07:54 localhost kernel: ieee1394: sbp2: reset requested > Jan 30 12:07:54 localhost kernel: ieee1394: sbp2: Generating IEEE-1394 > bus reset > Jan 30 12:07:59 localhost kernel: scsi: device set offline - not ready > or command retry failed after bus reset: host 0 channel 0 id 0 lun 0 There's the reason right there; the system is having trouble talking to the drive. I have seen similar message on the lkml, but they appear to be related to work on the VM (i.e., related to the rmap patches and their effect on the disk elevator/write scheduler). But, I don't think that has any bearing on your problem. You would try switching to a different kernel if you have any variations available, but I'm not convinced that would make much difference. Is the hardware definitely known working? If you can at all, that would be the thing to determine first, if you haven't already - it's not the most likely solution, but it is something easy to check before doing anything else. There are some parameters to the sbp2 module which you might try; sbp2_serialize_io=1 and sbp2_max_speed=0 being potentially the most interesting settings. The former looks most juicy, I would give that a go on it's own. Hope this helps some. Cheers, Alex.
Attachment:
signature.asc
Description: This is a digitally signed message part