Junos
Highlighted
Junos

this can not be good: getty[ ]: tcsetattr /dev/ttyu1: Invalid argument & init: getty repeating too quickly on port /dev/ttyu1, sleeping 30 secs

‎10-25-2019 10:16 AM

I have a sample of 236(!!)  EX2300C switches in a test setup waiting for deployment. 

In investigating occurences of Swizzle Reboot (> show chassis routing-engine)  and plain zombification (PR1442376), 

I have started turning on messages displays (`monitor start messages) from time to time. 

If I monitor let's say 20 of them, I am bound to find a couple with the following messages occurring. 

this goes on forever !!!!!!! it clog the messages files ...

I used to see these doing forensic on switches that had rebooted , but I start now seeing it on live switches.

what is it ?

  • all the switches are on the same vlan, with only one port connected for the moment.
  • They all share the same basic config, except for indvidual host-names ans IP addresses.
  • We have disconnected the VMware VM running Junos Space and Network Director for now
  • what is causing this ???????? this can not be good

I already have service request opened with JTAC.  I'll keep the forum posted if anything is found. 

thanks for your help,

Michel Lapointe

Oct 25 13:01:19  cslt-bearn-01-BYPASS init: getty repeating too quickly on port /dev/ttyu1, sleeping 30 secs
Oct 25 13:01:49  cslt-bearn-01-BYPASS getty[76714]: tcsetattr /dev/ttyu1: Invalid argument
Oct 25 13:01:50  cslt-bearn-01-BYPASS getty[76895]: tcsetattr /dev/ttyu1: Invalid argument
Oct 25 13:01:50  cslt-bearn-01-BYPASS getty[76896]: tcsetattr /dev/ttyu1: Invalid argument
Oct 25 13:01:50  cslt-bearn-01-BYPASS getty[76903]: tcsetattr /dev/ttyu1: Invalid argument
Oct 25 13:01:51  cslt-bearn-01-BYPASS getty[76904]: tcsetattr /dev/ttyu1: Invalid argument
Oct 25 13:01:51  cslt-bearn-01-BYPASS init: getty repeating too quickly on port /dev/ttyu1, sleeping 30 secs
Oct 25 13:02:21  cslt-bearn-01-BYPASS getty[76905]: tcsetattr /dev/ttyu1: Invalid argument
Oct 25 13:02:21  cslt-bearn-01-BYPASS getty[77086]: tcsetattr /dev/ttyu1: Invalid argument
Oct 25 13:02:22  cslt-bearn-01-BYPASS getty[77087]: tcsetattr /dev/ttyu1: Invalid argument
Oct 25 13:02:22  cslt-bearn-01-BYPASS dc-pfe: Version 18.3R2-S2.1 by builder on 2019-09-26 14:10:08 UTC
Oct 25 13:02:22  cslt-bearn-01-BYPASS fpc0 Version 18.3R2-S2.1 by builder on 2019-09-26 14:10:08 UTC 
Oct 25 13:02:22  cslt-bearn-01-BYPASS getty[77092]: tcsetattr /dev/ttyu1: Invalid argument
Oct 25 13:02:22  cslt-bearn-01-BYPASS getty[77095]: tcsetattr /dev/ttyu1: Invalid argument
Oct 25 13:02:22  cslt-bearn-01-BYPASS init: getty repeating too quickly on port /dev/ttyu1, sleeping 30 secs
Oct 25 13:02:53  cslt-bearn-01-BYPASS getty[77096]: tcsetattr /dev/ttyu1: Invalid argument
Oct 25 13:02:53  cslt-bearn-01-BYPASS getty[77275]: tcsetattr /dev/ttyu1: Invalid argument
Oct 25 13:02:53  cslt-bearn-01-BYPASS getty[77278]: tcsetattr /dev/ttyu1: Invalid argument
Oct 25 13:02:54  cslt-bearn-01-BYPASS getty[77283]: tcsetattr /dev/ttyu1: Invalid argument
Oct 25 13:02:54  cslt-bearn-01-BYPASS getty[77284]: tcsetattr /dev/ttyu1: Invalid argument
Oct 25 13:02:54  cslt-bearn-01-BYPASS init: getty repeating too quickly on port /dev/ttyu1, sleeping 30 secs
Oct 25 13:03:24  cslt-bearn-01-BYPASS getty[77287]: tcsetattr /dev/ttyu1: Invalid argument
Oct 25 13:03:25  cslt-bearn-01-BYPASS getty[77466]: tcsetattr /dev/ttyu1: Invalid argument
Oct 25 13:03:25  cslt-bearn-01-BYPASS getty[77469]: tcsetattr /dev/ttyu1: Invalid argument
Oct 25 13:03:25  cslt-bearn-01-BYPASS getty[77474]: tcsetattr /dev/ttyu1: Invalid argument
Oct 25 13:03:26  cslt-bearn-01-BYPASS getty[77475]: tcsetattr /dev/ttyu1: Invalid argument
Oct 25 13:03:26  cslt-bearn-01-BYPASS init: getty repeating too quickly on port /dev/ttyu1, sleeping 30 secs
Oct 25 13:03:56  cslt-bearn-01-BYPASS getty[77478]: tcsetattr /dev/ttyu1: Invalid argument
Oct 25 13:03:56  cslt-bearn-01-BYPASS getty[77657]: tcsetattr /dev/ttyu1: Invalid argument
Oct 25 13:03:57  cslt-bearn-01-BYPASS getty[77660]: tcsetattr /dev/ttyu1: Invalid argument
Oct 25 13:03:57  cslt-bearn-01-BYPASS getty[77665]: tcsetattr /dev/ttyu1: Invalid argument
Oct 25 13:03:57  cslt-bearn-01-BYPASS getty[77666]: tcsetattr /dev/ttyu1: Invalid argument
Oct 25 13:03:57  cslt-bearn-01-BYPASS init: getty repeating too quickly on port /dev/ttyu1, sleeping 30 secs
Oct 25 13:04:28  cslt-bearn-01-BYPASS getty[77667]: tcsetattr /dev/ttyu1: Invalid argument
Oct 25 13:04:28  cslt-bearn-01-BYPASS getty[77848]: tcsetattr /dev/ttyu1: Invalid argument
Oct 25 13:04:28  cslt-bearn-01-BYPASS getty[77851]: tcsetattr /dev/ttyu1: Invalid argument
Oct 25 13:04:29  cslt-bearn-01-BYPASS getty[77856]: tcsetattr /dev/ttyu1: Invalid argument
Oct 25 13:04:29  cslt-bearn-01-BYPASS getty[77857]: tcsetattr /dev/ttyu1: Invalid argument
Oct 25 13:04:29  cslt-bearn-01-BYPASS init: getty repeating too quickly on port /dev/ttyu1, sleeping 30 secs
Oct 25 13:05:00  cslt-bearn-01-BYPASS getty[77860]: tcsetattr /dev/ttyu1: Invalid argument
Oct 25 13:05:00  cslt-bearn-01-BYPASS /usr/sbin/cron[78040]: (root) CMD (   /usr/libexec/atrun)
Oct 25 13:05:00  cslt-bearn-01-BYPASS getty[78042]: tcsetattr /dev/ttyu1: Invalid argument
Oct 25 13:05:00  cslt-bearn-01-BYPASS getty[78045]: tcsetattr /dev/ttyu1: Invalid argument
Oct 25 13:05:01  cslt-bearn-01-BYPASS getty[78050]: tcsetattr /dev/ttyu1: Invalid argument
Oct 25 13:05:01  cslt-bearn-01-BYPASS getty[78051]: tcsetattr /dev/ttyu1: Invalid argument
Oct 25 13:05:01  cslt-bearn-01-BYPASS init: getty repeating too quickly on port /dev/ttyu1, sleeping 30 secs
Oct 25 13:05:31  cslt-bearn-01-BYPASS getty[78052]: tcsetattr /dev/ttyu1: Invalid argument
Oct 25 13:05:32  cslt-bearn-01-BYPASS getty[78233]: tcsetattr /dev/ttyu1: Invalid argument
Oct 25 13:05:32  cslt-bearn-01-BYPASS getty[78234]: tcsetattr /dev/ttyu1: Invalid argument
Oct 25 13:05:32  cslt-bearn-01-BYPASS getty[78241]: tcsetattr /dev/ttyu1: Invalid argument
Oct 25 13:05:32  cslt-bearn-01-BYPASS getty[78242]: tcsetattr /dev/ttyu1: Invalid argument
Oct 25 13:05:32  cslt-bearn-01-BYPASS init: getty repeating too quickly on port /dev/ttyu1, sleeping 30 secs
Michel Lapointe, GIRAT
23 REPLIES 23
Highlighted
Junos

Re: this can not be good: getty[ ]: tcsetattr /dev/ttyu1: Invalid argument & init: getty repeating too quickly on port /dev/ttyu1, sleeping 30 secs

‎10-25-2019 08:31 PM

Hi,

 

This is poiting out for a console port side issue, 

Please check for any interupts on console port, try swapping the console cable or the peer side port 

 

Thank you

Prabin

Please mark the solution accepted, if this solution helped you

 

Highlighted
Junos

Re: this can not be good: getty[ ]: tcsetattr /dev/ttyu1: Invalid argument & init: getty repeating too quickly on port /dev/ttyu1, sleeping 30 secs

‎10-26-2019 07:34 PM

hello Prabin, 

this was also the first answer from JTAC.

Unfortunately, none of the 236 switches are connected to console port. for the test before deployment, Only port 11 is connected. Console port was last touched in early september. 

Michel

Highlighted
Junos

Re: this can not be good: getty[ ]: tcsetattr /dev/ttyu1: Invalid argument & init: getty repeating too quickly on port /dev/ttyu1, sleeping 30 secs

‎10-28-2019 11:04 AM

this is getting interesting .

  • 2 of my sick switches went into swizzle reboot and were fine after. 
  • no rj45 or miniusb console port are connected to any switch. If I take a healthy switch and connect to both console port, I can open putty sessions on each BUT...
  • If I try the same thing on a sick switches, mini-usb does not communicate
  • I can take a sick switch and issue a port  set system ports auxiliary port-type rj45 disable and the getty error messages disappear
  • rollback brings the getty error messages back. It has to be a rollback: just set system ports auxiliary port-type rj45  leave the ports in disable state. In fact, I can't find a command to brign that port out of disdable !!!

show system ports
auxiliary {
port-type rj45;
disable;
}

not sure what to make of all this.... 

Michel

 

Michel Lapointe, GIRAT
Highlighted
Junos

Re: this can not be good: getty[ ]: tcsetattr /dev/ttyu1: Invalid argument & init: getty repeating too quickly on port /dev/ttyu1, sleeping 30 secs

‎10-28-2019 08:20 PM

I'm not sure what 'set system ports auxiliary port-type rj45' is supposed to do since that would seemingly conflict with the console port, which defaults to rj-45. There is no auxillary port anyway, so the whole configuration process makes no sense.

 

If you want both the rj-45 and usb console ports to be active at the same time the following works, at least on my 2300-C running 19.2R1.

 

delete system ports
set system ports auxiliary port-type mini-usb
Highlighted
Junos

Re: this can not be good: getty[ ]: tcsetattr /dev/ttyu1: Invalid argument & init: getty repeating too quickly on port /dev/ttyu1, sleeping 30 secs

‎10-29-2019 05:21 AM

Bonjour Smicker,  thanks for pitching in. 

I am not sure myself what this command is supposed to do! I am still trying to understand 

the miniusb- RJ45 thing and also the auxiliary / console difference that I still can't figure. 

All I know for (almost) sure is that:

  • a normal switch can be accessed through both it's console port: RJ45 and miniusb simultenously with it,s basic configuration
  • a switch vomiting getty statements stop communicating through it's miniusb port. The connection come up (my portable see a new COM port number) but no communications take place. two signs that this can not be good.
  • set system ports auxiliary port-type rj45 disable stop the vomiting
  • the switch is now in this configuration  
    show system ports
    auxiliary {
    port-type rj45;
    disable;
    }
  • I was expecting to undo this by issuing set system ports auxiliary port-type rj45. the command is accepted and committed but show system port still show the same state.!!! (that's bizarre ...)
  • I have to do a rollback  to get back to auxiliary port-type rj45 state. (that alone is peculiar...)
  • the switch will then start vomiting again
  • a switch vomiting is almost sure to end up doing a swizzle reboot eventually. this my experience so far.
  •  if disabling the miniusb port cure it, I will gladly do it on all my switches, but I want to understand what I am doing first. 

It goes without saying that I am not doing this on a live switch!.  

 

show chassis routing-engine  will show you the last reboot reason, including swizzle reboot.

also, if you have a 2300-c running 19.2, you may end up with a zombie switch ... see PR14422376 that was updated sunday  and have a look at 

Re: EX2300-48T Stop working after random time after upgrade to 19.1R1.6

 

    Michel
Michel Lapointe, GIRAT
Highlighted
Junos

Re: this can not be good: getty[ ]: tcsetattr /dev/ttyu1: Invalid argument & init: getty repeating too quickly on port /dev/ttyu1, sleeping 30 secs

‎10-29-2019 09:29 AM

Good Day,

 

According to public PR1442376 https://prsearch.juniper.net/InfoCenter/index?page=prcontent&id=PR1442376 , fix will be available in 18.4R3 and 19.2R2.

 

Thanks!

Highlighted
Junos

Re: this can not be good: getty[ ]: tcsetattr /dev/ttyu1: Invalid argument & init: getty repeating too quickly on port /dev/ttyu1, sleeping 30 secs

‎10-29-2019 09:44 AM

bonjour Deimos, 

can't wait for them to be available and try.

Checking hourly for that !!

I was alos told by one of our Juniper rep that 18.2R3-S2 should fix this and other issues and be available early november. 

Michel

Michel Lapointe, GIRAT
Highlighted
Junos

Re: this can not be good: getty[ ]: tcsetattr /dev/ttyu1: Invalid argument & init: getty repeating too quickly on port /dev/ttyu1, sleeping 30 secs

‎10-29-2019 12:52 PM

awright, so ...

15/236  switches are vomiting getty statements  

I applied the set system ports auxiliary port-type rj45 disable command to all of them

I lost connection to the mini-usb console port on all the switches I manually checked. Go figure !!!!!!

I still have connection to rj45 console ports. 

So far, on all the switches I checked, vomiting topped. 

I'll check tomorrow if this had any effect on the swizzle reboot issue, or if a switch is going to start vomiting. 

Michel

Michel Lapointe, GIRAT
Highlighted
Junos

Re: this can not be good: getty[ ]: tcsetattr /dev/ttyu1: Invalid argument & init: getty repeating too quickly on port /dev/ttyu1, sleeping 30 secs

‎10-29-2019 08:02 PM

Did you read the configuration change I suggested?

Highlighted
Junos

Re: this can not be good: getty[ ]: tcsetattr /dev/ttyu1: Invalid argument & init: getty repeating too quickly on port /dev/ttyu1, sleeping 30 secs

‎10-30-2019 05:04 AM

hello smicker, 

the priority now is finding a way to stop the vomiting of getty request and the set system port auxport-type rj45 disable seems to do the trick, at least for the last 12 hours on the machine that were sick. 

Losing the miniusb console is a small price to pay. I would just like though to understand the link between disabling a rj45 and losing the miniusb.

I'll be checking the switches today. I'll try the minusb command. I expect the vomiting to reappear, but only test will tell. Also, I am wondering why I have to issue a delete port command before. And I still don't understand what is this" auxiliary" access . 

 

Since yesterday, 2/236 went zombie (PR1442376) , which is something I am geting used to by now :-(

michel

Michel Lapointe, GIRAT
Highlighted
Junos

Re: this can not be good: getty[ ]: tcsetattr /dev/ttyu1: Invalid argument & init: getty repeating too quickly on port /dev/ttyu1, sleeping 30 secs

‎10-30-2019 11:23 AM

If you want both the rj-45 and usb console ports to be active at the same time the following works, at least on my 2300-C running 19.2R1.

 

delete system ports
set system ports auxiliary port-type mini-usb

so I have been fiddling quite a bit on this. First of all, I was wondering what can "port auxiliary" commands do on a switch that do not have auxiliary ports. here is a couple of thing I found...

  • rj45 console port is always on, even after delete system ports. Good design on Juniper.
  • The command will disable the miniusb port, though.
  • you would expect set system ports console port-type mini-usb to reactivate it. It does not.
  • you may expect set system ports console port-type rj45 to reactivate it. It does not.
  • you would then try set system ports auxiliary port-type mini-usb. It does work !!!
  • but by curiosity, you would disable it again by delete system ports and check mini-usb is down. it is. 
  • you would the try set system port auxiliary port-type rj45 and tell yourself no, it cannot possibly activate de mini-usb ports. But it does !!!!
  • all this time, I have a ping going on on the console port updating every seconds.... 

at that point, I put the switch back to set system ports auxiliary port-type rj45 disable because by sheer luck, I found it to make the vomiting of getty statement attempting to connect to the ttuy port stops. so that is a good thing. I still lose mini-usb console port connection, which does not bother me. But I would really like someone to explain to me why disabling auxiliary port-type 45   ends up deactivte the console mini-usb. 

feel free to try and duplicate and keep me posted. I am still waiting for the new image that solve PR1442376

Michel

 

Michel Lapointe, GIRAT
Highlighted
Junos

Re: this can not be good: getty[ ]: tcsetattr /dev/ttyu1: Invalid argument & init: getty repeating too quickly on port /dev/ttyu1, sleeping 30 secs

‎10-31-2019 05:48 AM

bonjour smicker,

 

just received this answer from Juniper on my service request ...

The auxiliary port is the miniUSB console connection -  on configuration based you can be able to manipulate console & auxiliary port.  As you has showed us in previous email when you disable the auxiliary port the miniUSB shouldn’t response to any output, it might deliver a COM port, but no outputs will be display.  

so I understand that any command sent to the auxiliary will affect the miniusb port. It's just confusing that I can use port-type rj45 and influence the mini-usb port. 

once you know it ... :-)

Michel Lapointe, GIRAT
Highlighted
Junos

Re: this can not be good: getty[ ]: tcsetattr /dev/ttyu1: Invalid argument & init: getty repeating too quickly on port /dev/ttyu1, sleeping 30 secs

‎11-04-2019 07:08 AM

OK, so ...

6 days now that my 236 EX2300-C have been running 18.3R2-S2.1 with the miniusb console port disable. during that time , I had :

  1.  no display of getty requests unless I turn the miniusb port up againfor a couple of minutes to check.
  2.  no swizzle reboot 

6 days without swizzle reboot on 236 switches: I may be on to something ...

 

next test will be taking place now: in the coming hour, I will reactivate the miniusbport on all switches and wait for a swizzle reboot that I believe would affect first one of the 15 switches that still are spilling getty request. 

 

Michel

 

Michel Lapointe, GIRAT
Highlighted
Junos

Re: this can not be good: getty[ ]: tcsetattr /dev/ttyu1: Invalid argument & init: getty repeating too quickly on port /dev/ttyu1, sleeping 30 secs

‎11-05-2019 06:56 AM

as of nov 5, 10:00,  I have 236 switches running with a beta image from Juniper that may solve PR1442376, and I have disabled the miniusb console port on all of them. So it is possible that in the coming days, I have no zombie switches neither swizzle reboot. Basically, I expect the "alarms" on my outlook folder that receive PRTG ping sensor warnings to be empty 

How about a daily post to show how things are going ???

Michel

Michel Lapointe, GIRAT
Highlighted
Junos

Re: this can not be good: getty[ ]: tcsetattr /dev/ttyu1: Invalid argument & init: getty repeating too quickly on port /dev/ttyu1, sleeping 30 secs

‎11-07-2019 04:58 AM

my 236 switches  on which I disabled miniusb port have been running 2.5 days with no swizzle reboot. 

I had one yesterday from one of our 8 prod switches that have not been modified. 

I believe I will correct this as of today and see what happen. Juniper is working on this issue on a Service Request.

Michel

Michel Lapointe, GIRAT
Highlighted
Junos

Re: this can not be good: getty[ ]: tcsetattr /dev/ttyu1: Invalid argument & init: getty repeating too quickly on port /dev/ttyu1, sleeping 30 secs

‎11-11-2019 05:54 AM
    Start time                     2019-11-04 14:04:20 EST
    Uptime                         6 days, 17 hours, 39 minutes, 55 seconds
    Last reboot reason             Router rebooted after a normal shutdown.

last monday, I received a pre-version 18.2R3-S2.7 that I installed on all my test switches and I also disabled the miniusb console port (set system ports aux port-type rj45 disable) . The switches have now been rtunning for 6.5 days with no zombies (PR1442376) or swizzle reboot . 

swizzle is being adressed in a Service Request by Juniper. 

Michel

Michel Lapointe, GIRAT
Highlighted
Junos

Re: this can not be good: getty[ ]: tcsetattr /dev/ttyu1: Invalid argument & init: getty repeating too quickly on port /dev/ttyu1, sleeping 30 secs

‎11-20-2019 04:52 AM

Quick update on this one...

this thread and another one were based on myself unable to deploy EX2300 switches due to 2 problems: loss of communication with the switches (PR1442376)  and random swizzle reboot (not sure if there is a PR for this, but I have 2 Service request so far with Juniper)

PR1442376: 

so 236 EX2300 switches running pre-release of 18.2R3S2.7 for 15 days now and no zombie switch. PR1442376 seems to be under control. Can't wait for the official release. 

SWIZZLE REBOOT

as for the getty request that seems to induce swizzle reboot, I was told by Juniper to check for defective cables connected to the miniusb port. Problem is that no cables are connected, so I decided to just turn it off (set system aux port-type rj45 disable turn off the miniusb console but the rj45 console still works. Go figure ...) .

The trick of shutting dow the miniusb console ports seems to work.

Out of the 236 switches, I have 34 that issue getty requests on ttyu1 and on which I left the miniusb console port open to compare.  all the other 200 switches had their miniusb port disabled and none of them swizzled reboot. but in the  last 2 weeks. I am up to 13 of the 34 switches that went swizzle reboot during that time.

(how do I determine if a switch issue getty request ? message start messages for 60 secs and watch for 

Oct 25 13:01:19  cslt-bearn-01-BYPASS init: getty repeating too quickly on port /dev/ttyu1, sleeping 30 secs
Oct 25 13:01:49  cslt-bearn-01-BYPASS getty[76714]: tcsetattr /dev/ttyu1: Invalid argument
Oct 25 13:01:50  cslt-bearn-01-BYPASS getty[76895]: tcsetattr /dev/ttyu1: Invalid argument
Oct 25 13:01:50  cslt-bearn-01-BYPASS getty[76896]: tcsetattr /dev/ttyu1: Invalid argument
Oct 25 13:01:50  cslt-bearn-01-BYPASS getty[76903]: tcsetattr /dev/ttyu1: Invalid argument
Oct 25 13:01:51  cslt-bearn-01-BYPASS getty[76904]: tcsetattr /dev/ttyu1: Invalid argument
Oct 25 13:01:51  cslt-bearn-01-BYPASS init: getty repeating too quickly on port /dev/ttyu1, sleeping 30 secs

so I will now turn off the miniusb on all my switches and I expect not to see a swizzle reboot anymore.

If that works, well, I seems to have a way to go to handle these 2 problems. 

Juniper is working on the swizzle reboot thing. In the meantime, if the trick prevent a switch to randomly reboot, well, I'll take it !!!

Michel

 

Michel Lapointe, GIRAT
Highlighted
Junos

Re: this can not be good: getty[ ]: tcsetattr /dev/ttyu1: Invalid argument & init: getty repeating too quickly on port /dev/ttyu1, sleeping 30 secs

‎12-16-2019 08:14 AM

well, a band aid is a bandaid: it,s not a cure.

I have 240  switches running 18.2R3S2.9 (the recommended EX23000 image) with also my trick of mini usb console port disable that dramatically reduced then number of swizzle reboot for 2 months. 

last friday, a switch swizzled reboot. :-( 

1 swizzle reboot in 2 months on 240 switches is not a lot, but there is a problem.  Unfortunately, no core dump are generated at the time. 

So I am going to re-enable the miniusb port to 

  • see if there is a resurgence in the swizzle reboot
  • confirm that the disabling make a difference
  • identify switches that emit getty request. I had identified 33 in november with the previous image that were consistently issuing getty request. That identification, which was concistent at the time,  is no longer valid. 

I'll keep this post updated with any useful development. 

Michel

Michel Lapointe, GIRAT
Highlighted
Junos

Re: this can not be good: getty[ ]: tcsetattr /dev/ttyu1: Invalid argument & init: getty repeating too quickly on port /dev/ttyu1, sleeping 30 secs

‎12-17-2019 06:22 AM

the re-enabling of the miniusb and "monitor start messages"  allowed me to check 2 things: 

  • 32/240 switches emit getty request.
  • 2 of them went swizzle reboot on me in the last 24 hours since I re-enabled the miniusb console port. what a coincidence .... :-)

there is no core dump associated with a swizzle reboot. I plan to disable the miniusb by tomorrow afternoon and leave it like this and see what happens in the holiday. 

 

I am still heartborken at the switch that swizzled reboot last friday even with the console port disable. I wonder if it's possible to disable this port at the kernel level ?????  it seems directly related to the swizzle reboot problem and I don't  !"/$%? need it ....

 

Michel

Michel Lapointe, GIRAT